실시간 분산 시스템을 위한 RTI Connext DDS

1. 데이터 중심의 혁명: DDS 표준 제대로 이해하기

분산 시스템의 세계는 끊임없이 진화해 왔습니다. 그 진화의 최전선에는 단순히 메시지를 주고받는 것을 넘어, 멀리 떨어진 애플리케이션들이 마치 하나의 거대한 공유 데이터베이스에 접속하듯 상호작용하는 ’데이터 중심(Data-Centric)’이라는 철학이 있습니다. 이 안내서의 첫 번째 파트에서는 RTI Connext DDS의 구체적인 기술을 파고들기 전에, 우리를 이 새로운 시대로 이끄는 DDS(Data Distribution Service) 표준의 근본적인 패러다임 전환을 깊이 있게 들여다볼 것입니다. 통신을 ’메시지 배달’이라는 낡은 관점에서 벗어나, 시스템 전체의 ’상태를 실시간으로 공유’하는 새로운 개념으로 이해하는 것. 이것이야말로 DDS의 진정한 힘을 깨닫는 가장 중요한 첫걸음입니다.

1.1 메시지를 넘어서: 데이터 중심 패러다임으로의 전환

오늘날 우리가 만드는 분산 시스템은 점점 더 복잡해지고, 예측 불가능하게 변하며, 수많은 부품이 눈 깜짝할 사이에 서로 정보를 주고받아야 하는 엄청난 과제에 직면해 있습니다. 이런 환경에서 데이터의 흐름을 얼마나 효과적으로 관리하느냐가 시스템의 성능, 안정성, 그리고 미래의 확장성까지 결정짓는 핵심 열쇠가 됩니다. 데이터 분산 서비스(DDS)는 바로 이 문제를 풀기 위해 태어난 표준 기술로, 기존 통신 방식들의 답답한 한계를 뛰어넘는 새로운 세상을 제안합니다.

1.1.1 전통적인 아키텍처의 한계

지금까지 분산 시스템을 만드는 데 사용되어 온 전통적인 통신 모델들은 저마다 쓸모가 있었지만, 복잡하고 역동적인 현대 시스템의 까다로운 요구를 만족시키기에는 명백한 한계를 보입니다.

1.1.1.1 클라이언트-서버 및 RPC

원격 프로시저 호출(RPC)에 기반한 클라이언트-서버 모델은 특정 서비스를 요청하고 응답을 받는 상호작용에 아주 효과적입니다. REST나 gRPC 같은 최신 기술들은 웹 서비스와 마이크로서비스 환경에서 지금도 널리 쓰이고 있죠.1 하지만 이 모델은 본질적으로 ’일대일 통화’에 최적화되어 있습니다. 시스템이 복잡해져서 수많은 구성 요소가 서로에게 끊임없이 데이터를 쏟아부어야 하는 ‘다자간 화상회의’ 같은 상황이 되면 어떨까요? 모든 연결을 일일이 관리해야 하므로 시스템 전체가 거미줄처럼 얽히는 ’강한 결합(tight coupling)’이 발생합니다. 이는 시스템의 유연성을 떨어뜨리고, 한 곳의 작은 문제가 시스템 전체를 마비시키는 도미노 현상을 일으킬 수 있는 취약한 구조를 만듭니다.3

1.1.1.2 메시지 중심 미들웨어 (예: MQTT)

사물 인터넷(IoT) 분야의 스타인 MQTT 같은 메시지 중심 미들웨어는 ‘발행-구독’ 모델을 사용해 클라이언트 간의 직접적인 연결을 끊어냅니다. 모든 통신은 중앙의 ’우체국(브로커)’을 거칩니다. 발행자는 우체국에 편지를 보내고, 구독자는 우체국에서 편지를 받아 가죠.4 이 방식은 클라이언트들을 효과적으로 분리하지만, 모든 통신이 몰리는 우체국 자체가 시스템 전체를 멈추게 할 수 있는 ’단일 장애점(Single Point of Failure)’이자 성능의 병목이 될 수 있다는 치명적인 약점을 안고 있습니다.5

더 근본적인 한계는 이들이 ’메시지 중심(Message-Centric)’이라는 점입니다. 우체국은 편지가 오고 갔다는 사실은 알지만, 편지 봉투 안에 무슨 내용이 들었는지는 전혀 관심이 없습니다.4 데이터의 의미를 해석하고, 필요한 정보만 걸러내고, 전체적인 상황을 파악하는 것은 모두 편지를 받은 개별 애플리케이션의 몫입니다. 이는 결국 애플리케이션을 점점 더 복잡하고 무겁게 만드는 주범이 됩니다.

1.1.2 DDS 패러다임: 중앙 서버 없는 P2P 데이터버스

DDS는 이런 문제들을 해결하기 위해 완전히 다른 길을 선택합니다. 바로 ‘데이터버스(Databus)’ 또는 ’글로벌 데이터 공간(Global Data Space)’이라는 개념입니다.6 이것은 마치 모든 분산 애플리케이션이 자신의 컴퓨터 안에 있는 거대한 공유 데이터베이스를 함께 읽고 쓰는 것처럼 상호작용하게 해주는 가상의 공간입니다.

이 패러다임의 핵심은 중앙 우체국(브로커)이 없는, 완전한 P2P(Peer-to-Peer) 구조에 있습니다. 시스템에 참여하는 모든 애플리케이션(Peer)들은 ‘자동 검색(auto-discovery)’ 기능을 통해 서로를 알아서 찾아내고, 필요한 데이터를 직접 주고받습니다.2 이 구조는 중앙 서버에 대한 의존성을 없애 단일 장애점을 원천적으로 차단하고, 데이터가 최단 경로로 전달되게 하여 지연 시간(latency)을 획기적으로 줄입니다. 이는 최고의 신뢰성과 실시간 성능이 필요한 시스템에 결정적인 장점을 제공합니다.5

1.1.3 데이터 중심: ’어떻게’가 아닌 ’무엇’에 집중하다

DDS 패러다임의 가장 혁신적인 부분은 바로 ’데이터 중심(Data-Centric)’이라는 철학입니다.7 이는 미들웨어가 단순히 데이터를 전달하는 것을 넘어, 그 데이터의

구조와 의미까지 이해한다는 뜻입니다.6

메시지 중심 시스템에서는 애플리케이션이 네트워크에서 받은 정체불명의 바이트 덩어리(blob of bytes)를 해석하는 힘든 일을 도맡아야 했습니다.10 반면, DDS에서는 애플리케이션이 “나는 ‘차량 위치’ 타입의 데이터를 공유하고 싶어“라고 자신의 ’의도’만 선언하면 됩니다. 그러면 미들웨어는 데이터의 내용에 기반해 직렬화, 라우팅, 필터링, 상태 관리 같은 복잡한 통신 문제를 알아서 처리해 줍니다.11 예를 들어, 구독자는 “온도가 30도 이상인 센서 데이터만 줘“라고 미들웨어에 요청할 수 있고, 미들웨어는 이 조건을 만족하는 데이터만 골라서 해당 구독자에게 전달합니다.

이러한 데이터 중심 상호작용은 발행-구독(Publish-Subscribe) 모델을 통해 이루어집니다. 발행자(Publisher)는 특정 주제(Topic)의 데이터를 글로벌 데이터 공간에 쓰고, 구독자(Subscriber)는 관심 있는 주제의 데이터를 읽어갑니다. 이 과정에서 둘은 서로의 존재나 위치를 전혀 알 필요 없이, 오직 데이터 자체에만 집중합니다. 이로 인해 시간과 공간에 대한 완전한 분리(decoupling)가 가능해집니다.11

이러한 패러다임의 전환은 단순한 기술의 차이를 넘어, 분산 시스템을 설계하는 철학의 근본적인 변화를 의미합니다. 기존 모델에서는 통신과 관련된 복잡한 코드(오류 처리, 데이터 변환, 상태 동기화 등)가 애플리케이션 곳곳에 흩어져 있었습니다. “일반적인 네트워킹 코드의 80%가 데이터 선택과 오류 처리에 쓰인다“는 분석이 이를 잘 보여줍니다.15 DDS는 이 모든 복잡성을 애플리케이션에서 떼어내, 고도로 최적화되고 표준화된 미들웨어 계층으로 옮겨놓습니다.

결과적으로 개발자는 골치 아픈 저수준 네트워킹이나 복잡한 오류 처리 대신, 시스템의 핵심 비즈니스 로직에만 온전히 집중할 수 있게 됩니다. 이는 개발 시간 단축, 테스트 부담 감소, 그리고 장기적인 유지보수 비용 절감으로 이어집니다. 따라서 시스템 설계자에게 DDS의 채택은 단순히 새로운 라이브러리를 하나 추가하는 것이 아니라, 복잡한 분산 시스템을 더 효율적이고 견고하게 만들기 위한 새로운 설계 패턴을 도입하는 전략적 결정이 되는 것입니다.

1.2 글로벌 데이터 공간의 아키텍처

DDS의 데이터 중심 철학이라는 큰 그림을 이해했다면, 이제 그 철학을 현실로 만드는 기술적인 뼈대를 살펴볼 차례입니다. DDS는 ’글로벌 데이터 공간’이라는 추상적인 개념을 구체적인 ’엔티티(Entity)’라는 부품들의 계층 구조와 표준화된 통신 규칙(프로토콜)을 통해 구현합니다. 이 장에서는 DDS 표준의 핵심 아키텍처를 분해하여, 개발자가 시스템을 만들 때 실제로 사용하게 될 기본 구성 요소들과 그들이 어떻게 상호작용하는지 명확하게 설명합니다.

1.2.1 DDS의 두 가지 계층: DCPS와 DLRL

DDS 표준은 두 가지 수준의 인터페이스를 정의하는데, 이는 애플리케이션의 필요에 따라 다른 수준의 추상화를 제공하기 위함입니다.7

• DCPS (Data-Centric Publish-Subscribe): 이름에서 알 수 있듯, DCPS는 DDS의 심장부이자 필수 계층입니다.7 데이터 중심의 발행-구독 모델을 위한 모든 기본 엔티티와 통신 메커니즘을 정의합니다. DCPS는 ’올바른 정보를 올바른 수신자에게 효율적으로 전달하는 것’에 모든 초점을 맞추며, 이 안내서에서 다루는 대부분의 개념(엔티티, QoS, 데이터 모델링 등)은 바로 이 DCPS 계층에 속합니다.17
• DLRL (Data-Local Reconstruction Layer): DLRL은 선택적으로 제공되는 상위 계층입니다.7 이 계층의 목적은 DCPS를 통해 받은 데이터를 애플리케이션의 객체 지향 코드에 더 쉽게 녹여낼 수 있도록 돕는 것입니다.18 DLRL은 수신된 데이터를 애플리케이션이 사용하는 로컬 객체로 재구성하는 작업을 단순화해주지만, 모든 DDS 구현체가 DLRL을 제공하는 것은 아니며, DCPS만으로도 완벽한 DDS 애플리케이션을 만들 수 있습니다.

1.2.2 핵심 DDS 엔티티 (구성 요소)

DCPS는 시스템을 구성하는 여러 엔티티들을 정의합니다. 이 엔티티들은 레고 블록처럼 계층적인 관계를 가지며, 각각 명확한 역할과 책임을 가집니다. 이들의 관계를 이해하는 것이 DDS 프로그래밍의 첫걸음입니다.

• DomainParticipantFactory: DDS 세계로 들어가는 유일한 문(door) 역할을 하는 싱글턴(Singleton) 팩토리 객체입니다. 모든 DDS 작업은 이 팩토리를 통해 DomainParticipant를 생성하는 것에서 시작됩니다.11

• DomainParticipant: 특정 ‘도메인(Domain)’ 내에서 애플리케이션의 참여를 나타내는 핵심 컨테이너입니다.11 도메인은 독립적인 통신 네트워크를 형성하는 논리적인 ’방(room)’과 같습니다. 서로 다른 도메인 ID를 가진

DomainParticipant들은 기본적으로 서로 통신할 수 없습니다.7

DomainParticipant는 또한 Publisher, Subscriber, Topic과 같은 다른 하위 엔티티들을 만들어내는 공장(factory) 역할도 합니다.11

• Topic: 발행자와 구독자를 연결하는 ’대화 주제’입니다. Topic은 세 가지 요소로 정의됩니다:

1. 고유한 이름: 도메인 내에서 유일한 문자열 이름 (예: "VehiclePosition", "/lidar_points").8

2. 데이터 타입: 해당 토픽으로 오고 갈 데이터의 명확한 구조 (예: VehiclePositionType 구조체).8

3. QoS 정책: 해당 토픽에 적용될 통신 품질 정책.

Topic은 글로벌 데이터 공간에서 특정 데이터의 흐름을 식별하는 가장 기본적인 단위입니다.11

• Publisher와 DataWriter:

• Publisher: 하나 이상의 DataWriter를 관리하는 그룹 매니저입니다.11

Publisher 수준에서 QoS 정책을 설정하여 소속된 모든 DataWriter에 한 번에 적용할 수 있습니다.

• DataWriter: 애플리케이션이 특정 Topic에 데이터를 실제로 발행(쓰기)하기 위해 사용하는 ’펜’과 같은 객체입니다.11 하나의

DataWriter는 하나의 Topic에 연결됩니다.

• Subscriber와 DataReader:

• Subscriber: 하나 이상의 DataReader를 관리하는 그룹 매니저입니다.11

Subscriber 수준에서도 QoS 정책 설정이 가능합니다.

• DataReader: 애플리케이션이 특정 Topic의 데이터를 구독(읽기)하기 위해 사용하는 ’눈’과 같은 객체입니다.11

DataReader는 수신된 데이터를 내부 캐시에 저장하고, 애플리케이션은 이 캐시에서 데이터를 가져옵니다.

이러한 계층적 엔티티 모델은 시스템 설계에 강력한 유연성을 줍니다. 예를 들어, 시스템 설계자는 Publisher 수준에서 전반적인 신뢰성 정책(RELIABLE)을 설정하고, 그중에서도 덜 중요한 특정 데이터를 발행하는 DataWriter에 대해서만 개별적으로 정책을 BEST_EFFORT로 재정의할 수 있습니다. 21의 QoS 적용 가능 엔티티 표와 [22]의 설명에서 볼 수 있듯이, 이러한 계층적 QoS 적용 방식은 반복적인 설정을 피하고 시스템의 통신 규칙을 명확하고 효율적으로 관리할 수 있게 해주는 핵심적인 설계 패턴입니다. 이는 단일 설정 파일로 모든 것을 제어하는 방식보다 훨씬 정교하고 확장성이 뛰어납니다.

1.2.3 와이어 프로토콜: 상호운용성을 위한 DDSI-RTPS

DDS 표준은 애플리케이션 프로그래밍 인터페이스(API)뿐만 아니라, 네트워크 상에서 데이터가 교환되는 방식, 즉 ’와이어 프로토콜(wire protocol)’까지 정의합니다. 이 표준 프로토콜이 바로 **DDSI-RTPS(DDS Interoperability Real-Time Publish-Subscribe Protocol)**입니다.17

RTPS의 가장 중요한 역할은 서로 다른 회사가 만든 DDS 구현체 간의 **상호운용성(interoperability)**을 보장하는 것입니다.17 즉, RTI Connext DDS로 만든 애플리케이션이 eProsima Fast DDS나 Eclipse Cyclone DDS로 만든 애플리케이션과 별도의 번역기(게이트웨이) 없이 자연스럽게 대화할 수 있는 것은 바로 이 RTPS라는 공용어 덕분입니다.25

RTPS는 다음과 같은 설계 원칙을 기반으로 합니다 26:

• 고성능 및 실시간성: 일반적으로 UDP와 같은 비연결형 프로토콜 위에서 동작하며, 지연 시간을 최소화하도록 설계되었습니다.
• 내결함성(Fault-tolerance): 중앙 브로커 없이 P2P로 통신하므로 단일 장애점이 없습니다.
• 플러그 앤 플레이(Plug-and-play): 동적 검색 메커니즘을 통해 새로운 참여자가 네트워크에 들어오면 자동으로 발견하고 통신을 시작합니다.
• 전송 계층 독립성: 주로 UDP/IP 멀티캐스트를 활용하여 효율적인 일대다 통신을 지원하지만 13, TCP와 같은 다른 전송 프로토콜 위에서도 동작할 수 있도록 유연하게 설계되었습니다.

결론적으로, DDS의 아키텍처는 애플리케이션 개발을 위한 풍부한 엔티티 모델(DCPS)과 이기종 시스템 간의 원활한 통신을 보장하는 표준 와이어 프로토콜(RTPS)의 환상적인 조합으로 이루어져 있습니다. 이 견고한 아키텍처는 개발자가 복잡한 분산 시스템을 만들 때 골치 아픈 저수준 네트워킹 문제에 얽매이지 않고, 데이터 중심의 설계에만 집중할 수 있도록 하는 강력한 기반을 제공합니다.

2. RTI Connext DDS 심층 분석

DDS 표준이라는 견고한 이론적 토대 위에서, 이제는 업계에서 가장 널리 쓰이는 상용 구현체 중 하나인 RTI Connext DDS를 깊이 있게 살펴볼 차례입니다. 이 파트에서는 RTI(Real-Time Innovations)가 제공하는 구체적인 제품군과 그 생태계를 분석하고, DDS의 가장 강력한 기능인 서비스 품질(QoS)을 실제 시스템 설계에 어떻게 적용하는지 실용적인 관점에서 탐구합니다. 이를 통해 독자는 추상적인 표준을 넘어 실제 프로젝트에서 마주하게 될 RTI Connext DDS의 구체적인 모습과 그 활용법을 이해하게 될 것입니다.

2.1 RTI Connext 제품 생태계

RTI는 단순히 DDS 표준 라이브러리 하나만 제공하는 회사가 아닙니다. 다양한 산업과 애플리케이션의 독특한 요구사항에 맞춰 특화된 제품군과 포괄적인 개발 도구를 포함하는 완성된 생태계를 구축했습니다. 잠재적인 사용자가 자신의 프로젝트에 가장 적합한 솔루션을 선택하기 위해서는 이 제품 생태계에 대한 이해가 필수적입니다.

2.1.1 RTI: 산업용 IoT 연결성의 선두주자

Real-Time Innovations(RTI)는 미션 크리티컬 및 산업용 분산 시스템을 위한 소프트웨어 프레임워크를 제공하는 세계적인 선도 기업입니다.28 RTI의 주력 제품인 Connext DDS는 국방, 항공우주, 자율주행차, 의료, 에너지 등 최고의 신뢰성과 실시간 성능이 요구되는 까다로운 분야에서 수많은 성공 사례를 통해 그 기술력을 입증해왔습니다.30 RTI는 DDS 표준화 과정에 깊이 관여해왔으며, 시장에서 가장 성숙하고 기능이 풍부한 DDS 구현체를 제공하는 것으로 평가받고 있습니다.

2.1.2 Connext 제품군

RTI는 다양한 시스템의 고유한 요구사항을 충족시키기 위해 여러 버전의 Connext 제품을 제공합니다. 각 제품은 공통된 DDS 코어 아키텍처를 공유하지만, 특정 사용 사례에 맞춰 기능, 라이선스, 인증 수준이 다릅니다. 마치 같은 자동차 모델이라도 기본형, 스포츠형, 안전 강화형, 오프로드형이 있는 것과 같습니다.

• Connext Professional: IIoT(산업용 사물 인터넷) 시스템 개발 및 통합을 위한 핵심 제품입니다. DDS 표준의 모든 핵심 기능을 포함하며, 다양한 개발 도구와 라이브러리를 제공하여 일반적인 분산 시스템 구축에 사용됩니다.28
• Connext Secure: OMG DDS Security 표준을 완벽하게 준수하는 보안 강화 버전입니다.33 인증, 접근 제어, 암호화 등 강력한 보안 기능을 제공하여, 국방, 의료, 핵심 기반 시설처럼 데이터 보호가 생명과도 같은 시스템에 적합합니다.28
• Connext Micro: 메모리와 CPU 자원이 극도로 제한된 소형 임베디드 시스템을 위해 설계된 경량 버전입니다. 작은 발자국(footprint)을 가지면서도 DDS의 핵심 통신 기능을 제공하여, 센서, 액추에이터 등 엣지 디바이스에 탑재하기에 이상적입니다.28
• Connext Cert: DO-178C(항공 소프트웨어), ISO 26262(자동차 기능 안전)와 같은 엄격한 안전 표준 인증을 받아야만 하는 시스템을 위한 제품입니다. 인증에 필요한 방대한 문서와 증거 자료(certification evidence)를 함께 제공하여, 항공, 자동차, 의료기기 등 안전이 최우선인(safety-critical) 시스템의 개발 및 인증 과정을 획기적으로 단축시켜 줍니다.28
• Connext Drive: ’소프트웨어 정의 차량(Software-Defined Vehicle, SDV)’이라는 최신 자동차 아키텍처 트렌드에 맞춰 특별히 제작된 솔루션입니다.37 AUTOSAR Adaptive, ROS 2와 같은 자동차 산업 표준과의 완벽한 통합을 지원하며, ECU부터 고성능 컴퓨팅 유닛에 이르는 차량 내 모든 구성 요소 간의 안정적인 실시간 데이터 흐름을 보장합니다.35

아래 표는 RTI Connext 제품군을 요약하여 각 제품의 목적과 특징을 명확히 보여줍니다. 이는 시스템 설계자가 프로젝트의 요구사항(예: 보안, 안전 인증, 자원 제약)에 따라 어떤 제품을 선택해야 할지 신속하게 판단하는 데 큰 도움을 줍니다.

2.1.3 핵심 구성 요소 및 전송 프로토콜

RTI Connext의 강력함은 다양한 개발 환경과 네트워크 인프라를 지원하는 유연성에서도 나옵니다.

• 광범위한 플랫폼 지원: Connext는 C, C++, C#/.NET, Java, Ada, Python, LabVIEW, MATLAB/Simulink 등 매우 폭넓은 프로그래밍 언어를 지원합니다.32 또한, 다양한 운영체제(Windows, Linux, VxWorks, QNX 등)와 CPU 아키텍처에서 동작하여, 서로 다른 종류의 시스템들을 완벽하게 통합할 수 있게 해줍니다.28
• 유연한 전송 프로토콜: 애플리케이션의 요구사항과 네트워크 환경에 맞춰 최적의 전송 프로토콜을 선택하거나 조합하여 사용할 수 있습니다.
• Shared Memory: 같은 컴퓨터 안의 프로세스끼리 통신할 때, 네트워크 스택을 거치지 않고 공유 메모리를 통해 데이터를 직접 교환하여 최고의 성능을 제공합니다.32
• UDP (Unicast & Multicast): LAN 환경에서 저지연, 고성능 통신을 위한 기본 프로토콜입니다. 특히 UDP 멀티캐스트는 하나의 데이터 패킷으로 여러 구독자에게 동시에 데이터를 전송할 수 있어 매우 효율적입니다.13
• TCP: 방화벽을 통과하기 쉽고 신뢰성 있는 연결이 보장되는 환경에서 사용됩니다.32
• TLS/DTLS: TCP 및 UDP 통신에 전송 계층 보안을 추가하여, 암호화된 보안 채널을 제공합니다.32

이처럼 RTI Connext는 특정 산업의 요구에 맞춘 전문화된 제품군과 다양한 개발 환경을 지원하는 유연성을 통해, 단순한 통신 라이브러리를 넘어 복잡한 분산 시스템을 구축하기 위한 포괄적인 솔루션 생태계를 제공합니다.

2.2 DDS의 심장: 서비스 품질(QoS) 마스터하기

DDS를 다른 모든 통신 미들웨어와 근본적으로 구별 짓는 가장 강력한 기능은 바로 서비스 품질(Quality of Service, QoS)입니다. 여기서 QoS는 단순히 ’더 빠르다’거나 ’더 신뢰할 수 있다’는 막연한 의미가 아닙니다. 시스템의 동작 방식 자체를 정의하는 수십 가지의 정교한 정책들의 집합입니다. 시스템 설계자는 이 QoS 정책들을 레고 블록처럼 조합하여, 애플리케이션 코드를 단 한 줄도 바꾸지 않고도 데이터의 전달 방식, 생명 주기, 리소스 사용량 등을 아주 세밀하게 제어할 수 있습니다. 이 장에서는 DDS의 심장이라 할 수 있는 QoS의 개념을 깊이 파고들어, 주요 정책들의 역할과 그들이 시스템 아키텍처에 어떤 영향을 미치는지 분석합니다.

2.2.1 QoS 계약: 요청(Request) 대 제공(Offered)의 의미

DDS QoS의 기본 동작 원리는 ‘계약(contract)’ 모델에 기반합니다. 통신에 참여하는 두 주체인 DataWriter와 DataReader는 각각 자신의 QoS 정책을 가지고 있습니다.

• DataWriter는 자신이 제공할 수 있는 서비스의 수준을 **‘제공(offered)’**합니다.
• DataReader는 통신 상대에게 요구하는 최소한의 서비스 수준을 **‘요청(requested)’**합니다.

두 엔티티 간의 통신은 오직 DataWriter가 제공하는 QoS가 DataReader가 요청하는 QoS를 만족시킬 수 있을 때, 즉 ’호환(compatible)’될 때만 성립됩니다.18 예를 들어,

DataReader가 “나는 모든 데이터를 빠짐없이 받아야 해”(RELIABLE)라고 요청했는데, DataWriter가 “나는 최선을 다해 보내겠지만 유실될 수도 있어”(BEST_EFFORT)라고만 제공한다면, 둘 사이의 통신은 이루어지지 않습니다. 이 ‘요청 대 제공’ 매칭 메커니즘은 시스템의 통신 정책이 설계자의 의도대로 강제되도록 보장하는, DDS의 견고함을 지탱하는 초석입니다.

2.2.2 기본 QoS 정책

모든 DDS 시스템 설계의 출발점이 되는 가장 기본적이고 중요한 QoS 정책들은 다음과 같습니다.

• Reliability (신뢰성): 데이터 전송을 얼마나 보장할지 결정합니다.8
• BEST_EFFORT: 데이터를 한 번만 전송하며, 전달을 보장하지 않습니다. 일반 우편과 비슷하며, 지연 시간에 민감하고 최신 데이터가 이전 데이터를 무의미하게 만드는 센서 데이터 스트리밍 등에 적합합니다. 성능 오버헤드가 가장 적습니다.
• RELIABLE: 데이터가 수신자에게 반드시 전달되는 것을 보장합니다. 등기 우편과 같습니다. DataWriter는 데이터를 보낸 후 DataReader로부터 확인 응답(ACK/NACK)을 기다리며, 데이터가 유실되면 재전송합니다. 상태 변경, 이벤트, 명령어 등 반드시 전달되어야 하는 데이터에 사용되며, BEST_EFFORT에 비해 성능 오버헤드가 발생합니다.21
• Durability (내구성): 데이터가 얼마나 오래 살아남을지, 그리고 늦게 참여하는 구독자에게 과거 데이터를 보여줄지를 정의합니다. 이는 시스템의 상태를 관리하는 데 매우 중요합니다.8
• VOLATILE: 휘발성. 구독자는 자신이 구독을 시작한 이후에 발행된 데이터만 받을 수 있습니다.
• TRANSIENT_LOCAL: DataWriter가 자신의 메모리에 데이터를 잠시 보관합니다. 새로운 구독자가 참여하면, 해당 DataWriter가 살아있는 동안은 보관된 최신 데이터를 받을 수 있습니다.
• TRANSIENT: 네트워크 상의 ’내구성 서비스’가 데이터를 저장합니다. 따라서 원본 DataWriter가 종료된 후에도 새로운 구독자가 참여하면 과거 데이터를 받을 수 있습니다.42
• PERSISTENT: 내구성 서비스가 데이터를 디스크와 같은 비휘발성 저장소에 저장합니다. 시스템 전체가 재시작되어도 데이터가 보존됩니다.
• History (이력): 각 데이터 인스턴스에 대해 DataReader 또는 DataWriter의 캐시에 얼마나 많은 데이터를 저장할지를 제어합니다.8
• KEEP_LAST (depth): 가장 최근의 depth개 만큼의 데이터 샘플만 유지합니다. 예를 들어 depth가 1이면, 항상 최신 값만 저장됩니다.
• KEEP_ALL: 리소스 한도 내에서 모든 이력 데이터를 저장합니다. RELIABLE 통신과 함께 사용될 때, DataWriter는 모든 DataReader가 모든 샘플을 수신할 때까지 데이터를 버리지 않습니다.41

2.2.3 미션 크리티컬 시스템을 위한 고급 QoS

기본 QoS 정책 외에도, DDS는 고가용성, 내결함성, 실시간 제어 등 미션 크리티컬 시스템의 복잡한 요구사항을 만족시키기 위한 강력한 고급 QoS 정책들을 제공합니다.

• Ownership & Ownership Strength (소유권 및 소유권 강도): 고가용성(High Availability) 시스템 구축을 위한 핵심 패턴입니다.
• OWNERSHIP 정책은 하나의 데이터 인스턴스(예: 특정 항공기의 위치 정보)를 여러 DataWriter가 동시에 업데이트할 수 있는지 여부를 결정합니다. SHARED는 다중 쓰기를 허용하고, EXCLUSIVE는 오직 하나의 DataWriter만이 해당 인스턴스를 ’소유’하고 업데이트할 수 있도록 제한합니다.41
• OWNERSHIP_STRENGTH는 EXCLUSIVE 소유권 환경에서 여러 DataWriter가 동일 인스턴스에 대한 소유권을 주장할 때, 누구에게 우선권을 줄지 결정하는 정수 값입니다. 더 높은 strength 값을 가진 DataWriter가 소유권을 획득합니다. 이를 통해 주(active)/대기(passive) 장애 극복(failover) 메커니즘을 아주 간단하게 구현할 수 있습니다.43
• Liveliness (활성 상태): 시스템이 특정 DataWriter가 여전히 ’살아있는지’를 판단하는 방법을 정의합니다. AUTOMATIC, MANUAL_BY_PARTICIPANT, MANUAL_BY_TOPIC과 같은 종류와 lease_duration(임대 기간) 매개변수를 통해, 특정 시간 동안 아무런 활동이 없는 DataWriter를 ’사망’한 것으로 간주하고 이에 대한 대응(예: 소유권 이전)을 할 수 있습니다. 이는 ’조용한 실패(silent failure)’를 감지하는 데 필수적입니다.46
• Deadline (마감 시간): DataWriter가 특정 period 내에 새로운 데이터를 생성하고, DataReader가 이를 수신할 것을 보장하는 계약입니다. 만약 마감 시간이 지켜지지 않으면, 양측의 리스너(listener) 콜백 함수가 호출되어 애플리케이션이 데이터의 ‘신선도(freshness)’ 문제를 인지하고 대응할 수 있게 합니다. 예를 들어, 제어 루프에 사용되는 센서 데이터가 제때 도착하지 않는 위험한 상황을 감지할 수 있습니다.43
• Partition (파티션): 데이터버스를 문자열 기반의 논리적인 공간으로 분할하는 메커니즘입니다. 동일한 Topic이라도 서로 다른 파티션에 속한 DataWriter와 DataReader는 통신할 수 없습니다. 이를 이용해 시스템을 격리하거나(예: “미국 지역” vs “유럽 지역”), 시스템의 동작 모드를 구분하거나(예: “테스트 모드” vs “운용 모드”), 혹은 멀티테넌시를 구현하는 등 유연한 데이터 흐름 관리가 가능합니다.21

이러한 고급 QoS 정책들은 독립적으로 동작하는 것이 아니라, 서로 유기적으로 결합하여 강력한 아키텍처 패턴을 형성합니다. 예를 들어, Ownership, Liveliness, Deadline 정책의 조합은 복잡한 고가용성 및 내결함성 시스템을 구축하는 선언적인 프레임워크를 제공합니다. 주 DataWriter는 높은 Ownership_Strength를 가집니다. 만약 이 DataWriter가 Liveliness를 잃거나(예: 프로세스 다운) Deadline을 위반하면(예: 프로세스 멈춤), 미들웨어는 이를 자동으로 감지하고, 다음으로 높은 strength를 가진 대기 DataWriter에게 데이터 인스턴스의 소유권을 즉시, 그리고 원활하게 이전합니다.44 이러한 정교한 장애 극복 로직은 일반적으로 수천 줄의 복잡한 애플리케이션 코드(하트비트, 상태 감시, 인계 로직 등)를 필요로 하지만, DDS에서는 몇 줄의 QoS 설정만으로 구현됩니다. 이는 미션 크리티컬 시스템에서 DDS가 갖는 독보적인 가치를 보여주는 대표적인 사례입니다.

2.2.4 QoS 구성 방법

DDS의 강력한 장점 중 하나는 이러한 복잡한 QoS 정책을 애플리케이션 코드와 분리하여 관리할 수 있다는 점입니다. QoS 정책은 일반적으로 **XML 프로파일(profile)**을 사용하여 정의됩니다.18 애플리케이션은 시작 시 이 XML 파일을 로드하여

DomainParticipant, DataWriter, DataReader 등을 생성할 때 특정 프로파일 이름을 참조하기만 하면 됩니다.

XML

<dds>
<qos_library name="MyLibrary">
<qos_profile name="ReliableTransientProfile">
<datawriter_qos>
<reliability>
<kind>RELIABLE_RELIABILITY_QOS</kind>
</reliability>
<durability>
<kind>TRANSIENT_LOCAL_DURABILITY_QOS</kind>
</durability>
<history>
<kind>KEEP_LAST_HISTORY_QOS</kind>
<depth>10</depth>
</history>
</datawriter_qos>
<datareader_qos>
</datareader_qos>
</qos_profile>
</qos_library>
</dds>

XML QoS 프로파일 예시 42

이러한 접근 방식은 시스템의 통신 동작을 애플리케이션 재컴파일 없이 변경할 수 있게 해주므로, 시스템 통합, 테스트, 현장 튜닝 과정에서 엄청난 유연성과 효율성을 제공합니다.

아래 표는 주요 QoS 정책과 그 아키텍처적 목적을 요약한 것입니다. 시스템 설계자는 이 표를 통해 “이 센서 데이터는 장애가 나도 괜찮도록 만들어야 해“와 같은 시스템 요구사항을 “Ownership을 EXCLUSIVE로 설정하고 Ownership_Strength 값을 다르게 부여하자“는 구체적인 DDS 구성으로 변환할 수 있습니다.

2.3 시스템의 언어 설계: 데이터 모델링과 진화

데이터 중심 아키텍처의 성공은 전적으로 잘 설계된 데이터 모델에 달려있습니다. 데이터 모델은 분산 시스템 내 모든 참여자가 소통하는 공통의 ’언어’이며, 시스템의 확장성, 유지보수성, 성능에 지대한 영향을 미칩니다. 이 장에서는 DDS 시스템의 근간이 되는 데이터 모델을 어떻게 정의하고, 시간이 지남에 따라 변화하는 요구사항에 맞춰 어떻게 진화시켜 나갈 수 있는지에 대한 핵심 원칙과 패턴을 다룹니다.

2.3.1 계약으로서의 데이터 모델

DDS 시스템 설계의 가장 중요한 첫 단계는 ’데이터 우선 사고(data-first thinking)’입니다.10 이는 애플리케이션의 구체적인 로직이나 통신 메커니즘을 고민하기 전에, 시스템 내에서 교환되어야 할 정보, 즉 공유 데이터 모델을 먼저 정의하는 것을 의미합니다. 이 접근 방식이 효과적인 이유는 데이터 모델이 시스템의 본질적인 “물리적 특성(physics of the system)“에 기반하여, 일시적인 애플리케이션의 사용 사례보다 훨씬 안정적이고 변하지 않는 경향이 있기 때문입니다.12 예를 들어, 항공 관제 시스템에서 ’비행 계획’이라는 데이터 모델은 특정 애플리케이션의 기능보다는 항공기 비행의 본질에 더 가깝습니다.

이렇게 잘 정의된 데이터 모델은 다음과 같은 역할을 합니다.

• 시스템 통합의 계약: 여러 팀이나 조직에서 각기 다른 시점에 개발한 구성 요소들을 일관된 방식으로 통합할 수 있는 기준을 제공합니다.
• 느슨한 결합(Loose Coupling) 촉진: 애플리케이션들은 데이터 모델이라는 추상화된 인터페이스를 통해 상호작용하므로, 특정 애플리케이션의 내부 로직 변경이 다른 애플리케이션에 미치는 영향을 최소화합니다.

2.3.2 IDL을 이용한 타입 정의

DDS에서는 특정 프로그래밍 언어에 종속되지 않는 방식으로 데이터 타입을 정의하기 위해 **IDL(Interface Definition Language)**을 사용합니다.52 IDL은 OMG(Object Management Group)에 의해 표준화된 언어로, 이를 통해

struct(구조체), sequence(동적 배열), 그리고 long, double, string과 같은 기본 타입을 조합하여 복잡한 데이터 구조를 정의할 수 있습니다.54

Code snippet

// 예시: 항공기 위치 정보를 위한 IDL 정의
module Aviation {
struct Position {
double latitude;
double longitude;
float altitude;
};

struct FlightPlan {
string flight_id; //@key
string origin;
string destination;
sequence<Position> waypoints;
};
};

개발자는 이렇게 IDL로 데이터 타입을 정의한 후, RTI Connext DDS가 제공하는 코드 생성기(rtiddsgen)를 실행합니다. 이 도구는 IDL 파일을 파싱하여 C++, Java, C# 등 선택한 프로그래밍 언어에 맞는 타입 클래스와 직렬화/역직렬화, 메모리 관리 등을 위한 보조 코드를 자동으로 생성해줍니다. 이를 통해 개발자는 플랫폼 간 데이터 표현 방식의 차이를 신경 쓸 필요 없이 타입-안전(type-safe)한 방식으로 데이터를 다룰 수 있습니다.

2.3.3 키(Key)의 결정적 중요성

DDS 데이터 모델링에서 가장 중요한 아키텍처 결정 중 하나는 키(key)의 사용 여부와 어떤 필드를 키로 지정할 것인가입니다.10 키는 데이터 스트림 내에서 고유한 ’실세계 객체(real-world object)’를 식별하는 역할을 합니다.

• 키가 없는(Unkeyed) 토픽: 해당 토픽으로 발행되는 모든 데이터는 단일 스트림 또는 단일 ’인스턴스(instance)’로 취급됩니다.
• 키가 있는(Keyed) 토픽: 토픽은 여러 개의 고유한 인스턴스를 포함할 수 있으며, 각 인스턴스는 IDL에서 @key 어노테이션으로 지정된 필드의 값에 의해 유일하게 식별됩니다. 예를 들어, 위 FlightPlan IDL에서 flight_id가 키이므로, “KAL007“과 “AAL123“은 동일한 FlightPlan 토픽 내의 서로 다른 두 인스턴스가 됩니다.

키를 사용하는 것은 미들웨어가 데이터를 인식하고 관리하는 방식을 근본적으로 바꾸며, 다음과 같은 막대한 이점을 제공합니다 7:

• 인스턴스별 QoS 적용: History, Deadline, Ownership과 같은 주요 QoS 정책을 토픽 전체가 아닌 개별 인스턴스 단위로 적용할 수 있습니다. 예를 들어, 각 항공편(flight_id)마다 마지막 10개의 위치 업데이트(History)를 유지하거나, 특정 항공편의 업데이트가 30초 이상 지연될 경우 경고(Deadline)를 발생시킬 수 있습니다.
• 인스턴스 생명주기 관리: 미들웨어는 새로운 키 값을 가진 데이터가 나타나면 ’새로운 인스턴스 생성’으로, 특정 키 값의 데이터가 더 이상 업데이트되지 않으면 ’인스턴스 비활성화’로 인지합니다. 애플리케이션은 이러한 생명주기 이벤트를 리스너를 통해 감지하여, 새로운 객체의 등장이나 기존 객체의 소실에 동적으로 대응할 수 있습니다.
• 효율적인 데이터 관리: 미들웨어는 각 인스턴스별로 별도의 내부 캐시와 리소스를 할당합니다. 이는 특정 인스턴스의 데이터 업데이트가 다른 인스턴스의 데이터를 덮어쓰는 것을 방지하고, 리소스 관리를 최적화합니다.

이러한 키의 개념은 관계형 데이터베이스의 기본 키(Primary Key)와 매우 유사합니다. [55]에서 지적하듯이, sequence를 사용하여 일대다 관계를 모델링하는 것(예: carpool 구조체 안에 sequence<car>를 포함)은 일반적인 안티패턴입니다. 이는 하나의 car 정보만 변경되어도 전체 carpool 객체를 네트워크로 재전송해야 하므로 매우 비효율적입니다. 올바른 접근 방식은 car를 별도의 키(carId)를 가진 토픽으로 만들고, 여기에 ’외래 키(foreign key)’처럼 carpoolId 필드를 추가하여 관계를 맺는 것입니다. 이처럼 DDS 데이터 모델링은 데이터베이스 스키마 설계와 유사한 깊이 있는 분석과 설계 원칙을 요구하며, 이는 시스템의 성능과 확장성을 좌우하는 핵심적인 아키텍처 활동입니다.

2.3.4 DDS-XTypes를 이용한 데이터 타입의 진화

장기간 운영되는 시스템에서 데이터 모델은 필연적으로 변화하고 진화합니다. **DDS-XTypes(Extensible and Dynamic Topic Types)**는 이러한 데이터 타입의 진화를 지원하기 위한 OMG 표준입니다.52 XTypes는 IDL에 추가적인 어노테이션을 도입하여,

DataWriter와 DataReader가 서로 약간 다른 버전의 데이터 타입을 사용하더라도 통신이 가능하도록 허용합니다.58

XTypes는 세 가지 ’확장성 종류(extensibility kind)’를 정의하며, 각각 유연성과 성능 간의 트레이드오프를 가집니다 57:

• @final: 기본값으로, 타입 변경을 허용하지 않습니다. DataWriter와 DataReader의 타입 구조가 완벽하게 일치해야만 통신이 가능합니다. 성능 오버헤드가 가장 적습니다.
• @appendable: 타입의 끝에 새로운 멤버를 추가하는 것을 허용합니다. 구버전의 DataReader는 자신이 모르는 새로운 필드를 무시하고, 신버전의 DataReader는 구버전의 DataWriter로부터 데이터를 받을 때 누락된 필드를 기본값으로 채웁니다. 하위 호환성을 유지하며 타입을 확장할 때 유용하며, 오버헤드가 적습니다.
• @mutable: 멤버의 추가, 제거, 순서 변경 등 가장 자유로운 타입 변경을 허용합니다. 가장 유연하지만, 각 필드를 식별하기 위한 메타데이터가 추가되므로 성능 오버헤드가 가장 큽니다. 장기적으로 데이터 모델의 큰 변화가 예상될 때 사용합니다.

또한, @optional 어노테이션을 사용하면 특정 멤버가 데이터에 포함되지 않을 수도 있음을 명시할 수 있어, 더욱 유연한 데이터 모델링이 가능합니다.54 이러한 XTypes 기능 덕분에, 시스템 전체를 동시에 중단하고 업그레이드할 필요 없이, 개별 구성 요소들을 점진적으로 개선하고 배포하는 것이 가능해집니다.

3. 고급 기능 및 미션 크리티컬 통합

DDS 표준의 기본 원리와 RTI Connext의 제품 생태계를 이해했다면, 이제는 Connext DDS를 가장 까다로운 시스템에 적용할 수 있게 만드는 고급 기능들을 탐구할 시간입니다. 이 파트에서는 단순한 데이터 교환을 넘어, 시스템의 신뢰성, 성능, 안전성을 보장하는 핵심 요소인 보안, 성능 엔지니어링, 그리고 기능 안전에 대해 심도 있게 다룹니다. 이러한 기능들은 Connext DDS가 단순한 통신 미들웨어가 아니라, 미션 크리티컬 시스템을 구축하기 위한 포괄적인 프레임워크임을 증명합니다.

3.1 데이터버스 보안: 신뢰할 수 있는 시스템을 위한 프레임워크

핵심 기반 시설, 국방, 의료 시스템에서 보안은 선택이 아닌 필수입니다. 데이터 유출, 변조, 또는 서비스 거부 공격은 치명적인 결과를 초래할 수 있습니다. Connext DDS는 OMG의 DDS Security 표준을 통해 데이터버스 자체에 내장된 강력하고 세분화된 보안 모델을 제공하여, 이러한 위협으로부터 시스템을 보호합니다.

3.1.1 DDS 보안 표준

DDS Security는 데이터 중심 통신 환경의 고유한 특성을 고려하여 설계된 보안 표준입니다.33 이는 전통적인 네트워크 보안 방식(예: VPN, TLS)과는 다른 접근 방식을 취합니다. 모든 통신을 하나의 암호화된 터널에 넣는 대신, DDS Security는 데이터 흐름 자체에 보안 속성을 부여하여 훨씬 더 정교한 제어를 가능하게 합니다. RTI Connext Secure는 이 OMG DDS Security 표준을 완벽하게 준수하는 상용 구현체입니다.33

3.1.2 Connext DDS Secure의 다섯 가지 기둥

DDS Security 프레임워크는 시스템을 보호하기 위한 다섯 가지 핵심 서비스를 정의하며, 이는 ’보안의 다섯 기둥’으로 불립니다. RTI Connext Secure는 이 모든 서비스를 플러그인 형태로 제공합니다.34

1. 인증 (Authentication): “당신은 누구인가?“에 답하는 과정입니다. 시스템에 참여하려는 애플리케이션(DomainParticipant)이 신뢰할 수 있는 주체인지 확인합니다. 일반적으로 공유된 인증 기관(Certificate Authority, CA)이 서명한 X.509 디지털 인증서 기반의 공개 키 기반 구조(PKI)를 사용하여 각 참여자의 신원을 검증합니다. 인증되지 않은 참여자는 데이터버스에 아예 접근할 수 없습니다.
2. 접근 제어 (Access Control): “당신은 무엇을 할 수 있는가?“를 결정합니다. 인증된 참여자라 할지라도 모든 작업을 허용하는 것은 아닙니다. 접근 제어는 서명된 ’권한 파일(permissions file)’을 통해 각 참여자가 어떤 Topic을 발행(publish)하거나 구독(subscribe)할 수 있는지, 어떤 Partition에 참여할 수 있는지를 세밀하게 통제합니다. 이를 통해 최소 권한 원칙을 시스템 전반에 강제할 수 있습니다.
3. 암호화 (Cryptography - 기밀성 및 무결성):

• 기밀성 (Confidentiality): 네트워크를 통해 전송되는 데이터를 AES-256과 같은 강력한 알고리즘으로 암호화하여, 인가되지 않은 자가 데이터를 엿듣더라도 그 내용을 알 수 없게 합니다.
• 무결성 (Integrity): HMAC-SHA256과 같은 메시지 인증 코드(MAC)를 사용하여 데이터가 전송 중에 변조되지 않았음을 보장합니다. 수신자는 데이터가 원본 그대로임을 확신할 수 있습니다.

4. 데이터 태깅 (Data Tagging): 데이터 스트림에 보안 관련 메타데이터(예: “비밀”, “대외비“와 같은 보안 등급)를 첨부하는 기능입니다. 이 태그 정보는 참여자 검색(discovery) 과정에서 교환되며, 접근 제어 플러그인이 이 정보를 바탕으로 동적인 접근 결정을 내리는 데 사용될 수 있습니다.
5. 로깅 (Logging): 모든 보안 관련 이벤트(예: 인증 성공/실패, 접근 거부, 암호화 오류 등)를 안전하게 기록하는 기능입니다. 이 로그는 시스템 감사나 보안 사고 발생 시 원인 분석(forensics)을 위한 중요한 자료로 활용됩니다. 로그 자체도 DDS를 통해 안전하게 전송하여 중앙에서 통합 관리할 수 있습니다.

3.1.3 아키텍처적 이점

DDS Security 모델은 전통적인 보안 방식에 비해 몇 가지 중요한 아키텍처적 이점을 제공합니다.

• 세분화된 제어 (Fine-grained Control): 가장 큰 장점은 보안 정책을 데이터버스 전체가 아닌, 개별 Topic이나 Partition 단위로 적용할 수 있다는 것입니다.33 이는 민감한 제어 명령어

Topic은 최고 수준으로 암호화하고 접근을 통제하는 반면, 덜 중요한 상태 정보 Topic은 무결성 검사만 수행하거나 아예 보안을 적용하지 않는 유연한 구성을 가능하게 합니다. 모든 데이터를 무차별적으로 암호화하는 TLS나 VPN 방식에 비해 성능 오버헤드를 최소화하고 시스템 자원을 효율적으로 사용할 수 있습니다.34

• 분산형 아키텍처 (Decentralized): DDS의 P2P 특성과 마찬가지로, DDS Security 역시 중앙 인증 서버나 키 관리 서버에 의존하지 않습니다.33 각 참여자는 자신의 보안 자격 증명(credential)을 가지고 다른 참여자와 직접 보안 핸드셰이크를 수행합니다. 이는 중앙 서버로 인한 단일 장애점이나 성능 병목을 제거하여, 시스템의 가용성과 확장성을 높입니다.

결론적으로, RTI Connext Secure는 데이터 중심 아키텍처에 최적화된 포괄적이고 강력한 보안 솔루션을 제공합니다. 이를 통해 개발자는 복잡한 보안 로직을 직접 구현하는 부담에서 벗어나, 선언적인 정책 설정을 통해 시스템의 보안 요구사항을 만족시킬 수 있습니다.

3.2 성능 엔지니어링: 확장성과 처리량

RTI Connext DDS는 극도의 저지연과 고처리량이 요구되는 실시간 시스템을 위해 설계되었습니다. 하지만 최상의 성능을 이끌어내기 위해서는 미들웨어의 동작 방식과 네트워크의 특성을 이해하고, 그에 맞는 적절한 튜닝을 적용하는 ‘성능 엔지니어링’ 과정이 필수적입니다. 이 장에서는 특히 대용량 데이터 전송과 관련된 주요 과제를 해결하고, 시스템 성능을 최적화하기 위한 실질적인 가이드라인을 제시합니다.

3.2.1 대용량 데이터 처리: DDS 단편화 대 IP 단편화

분산 시스템에서 비디오 스트림, LIDAR 포인트 클라우드, 고해상도 이미지 등 대용량 데이터를 전송하는 것은 흔한 일입니다. 이때 데이터의 크기가 네트워크의 최대 전송 단위(Maximum Transmission Unit, MTU)를 초과하면 ’단편화(fragmentation)’가 발생합니다.

• IP 단편화의 문제점: DDS 설정을 별도로 하지 않은 상태에서 MTU보다 큰 데이터를 UDP로 전송하면, 운영체제의 IP 계층에서 데이터그램을 여러 개의 IP 패킷으로 자동 분할합니다. 이 방식은 구현이 간단해 보이지만 매우 취약합니다. 단편화된 IP 패킷 중 단 하나라도 유실되면, 수신 측에서는 전체 UDP 데이터그램을 재조립할 수 없어 전체 데이터를 폐기합니다. 신뢰성 있는 통신을 위해 전체 데이터그램을 재전송해야 하므로 네트워크 효율이 급격히 떨어집니다.60
• DDS 단편화의 이점: 이러한 문제를 해결하기 위해 DDS는 미들웨어 레벨에서 자체적인 단편화 메커니즘을 제공합니다. DataWriter는 대용량 데이터를 전송하기 전에 작은 ’DDS 단편(DDS fragment)’들로 분할하여 각각을 별도의 네트워크 패킷에 담아 보냅니다. 이 방식의 핵심 이점은 DDS의 신뢰성 프로토콜과 연동된다는 점입니다. RELIABLE QoS를 사용할 경우, 수신 측 DataReader는 유실된 단편만 식별하여 DataWriter에게 재전송을 요청할 수 있습니다. 전체 데이터를 다시 보내는 대신, 유실된 작은 조각만 복구하므로 네트워크 대역폭을 매우 효율적으로 사용할 수 있습니다.60

DDS 단편화를 활성화하는 방법은 전송 프로토콜의 message_size_max 속성을 네트워크 MTU(일반적으로 이더넷 환경에서 약 1500 bytes)와 유사한 값으로 설정하는 것입니다. 이렇게 하면 DDS는 이 크기를 초과하는 데이터를 자동으로 단편화하여 전송합니다.

3.2.2 비동기 발행 및 흐름 제어

DDS에서 DataWriter의 write() 함수를 호출하면 기본적으로는 동기(synchronous) 방식으로 동작합니다. 즉, write() 함수는 데이터가 미들웨어의 내부 큐를 거쳐 네트워크 전송 버퍼로 복사될 때까지 블로킹(blocking)될 수 있습니다. 이는 애플리케이션의 실시간성을 저해하는 요인이 될 수 있습니다.

• 비동기 발행 (Asynchronous Publishing): PUBLISH_MODE QoS 정책을 ASYNCHRONOUS_PUBLISH_MODE_QOS로 설정하면, write() 함수는 데이터를 내부 큐에 넣고 즉시 반환됩니다.62 실제 데이터 전송은

Publisher에 의해 관리되는 별도의 백그라운드 스레드가 담당합니다.63 이 방식의 장점은 다음과 같습니다 62:

• 애플리케이션의 주요 실행 스레드가 네트워크 I/O 작업으로 인해 지연되는 것을 방지하여, 더 예측 가능한(deterministic) 동작을 보장합니다.

• 여러 개의 작은 데이터를 모아 하나의 네트워크 패킷으로 전송(coalescing)하여 네트워크 효율을 높일 수 있습니다.

• 흐름 제어 (FlowControllers): 비동기 발행은 ’흐름 제어기(FlowController)’와 함께 사용될 때 더욱 강력한 성능 제어 능력을 발휘합니다.63 흐름 제어기는 비동기 발행 스레드가 데이터를 전송하는 속도를 조절하는 역할을 합니다. 이는 매우 빠른

DataWriter가 상대적으로 느린 DataReader나 네트워크 자체를 압도하여 패킷 손실을 유발하는 ‘임피던스 불일치(impedance mismatch)’ 문제를 해결하는 데 필수적입니다.61 RTI Connext는

DDS_FIXED_RATE_FLOW_CONTROLLER_NAME과 같이 미리 정의된 흐름 제어기를 제공하며, 사용자가 직접 커스텀 흐름 제어기를 구현할 수도 있습니다.

3.2.3 성능 튜닝 가이드

최적의 성능을 달성하기 위해서는 시스템 전반에 걸친 체계적인 튜닝이 필요합니다. 다음은 65, 65, 65의 내용을 종합한 핵심 튜닝 절차입니다.

1. 벤치마킹 및 기준 설정:

• 성능 문제를 논하기 전에, 현재 하드웨어와 네트워크 환경에서의 기준 성능을 측정하는 것이 중요합니다. RTI가 제공하는 rtiperftest 도구는 처리량(throughput)과 지연 시간(latency)을 측정하는 표준화된 방법을 제공합니다.65 이를 통해 “현재 우리 시스템이 기대치에 미치지 못하고 있는가?“에 대한 객관적인 데이터를 확보할 수 있습니다.

2. 운영체제(OS) 튜닝:

• 대부분의 범용 운영체제는 고성능 네트워킹에 최적화되어 있지 않습니다. 대용량 데이터를 처리하기 위해서는 OS 커널 파라미터, 특히 UDP 소켓 버퍼 크기를 늘려주는 작업이 거의 항상 필요합니다. Linux에서는 sysctl.conf 파일을, Windows에서는 레지스트리를 수정하여 버퍼 크기를 튜닝할 수 있습니다.67

3. DDS 전송 및 QoS 튜닝:

• 네트워크 인터페이스 명시: 시스템에 여러 네트워크 인터페이스(NIC)가 있는 경우, DDS가 의도치 않은 인터페이스를 사용할 수 있습니다. allow_interfaces 및 deny_interfaces 속성을 사용하여 DDS가 통신에 사용할 NIC를 명시적으로 지정해야 합니다.65
• 전송 버퍼 튜닝: DDS 전송 계층의 송수신 버퍼 크기를 OS 수준에서 튜닝한 값과 일치시키거나 충분히 크게 설정해야 합니다.
• QoS 설정 검토: RELIABLE QoS가 불필요한 곳에 사용되고 있지는 않은지, heartbeat_period와 같은 신뢰성 관련 파라미터가 현재 네트워크 상황에 적합한지 검토해야 합니다. 작은 샘플을 고속으로 전송할 때는 batching 기능을 활성화하여 처리량을 높일 수 있습니다.65

4. 진단 도구 활용:

• RTI Admin Console & Monitor: 이 도구들은 실행 중인 DDS 시스템의 상태를 시각적으로 보여주는 가장 강력한 진단 도구입니다. 참여자 간의 연결 상태, QoS 불일치, 패킷 유실, ACK/NACK 통계 등을 실시간으로 확인하여 문제의 원인을 신속하게 파악할 수 있습니다.65
• 로깅 및 로그 파서: DDS 로깅을 활성화하고 RTI Log Parser를 사용하면, 내부 동작에 대한 상세한 정보를 얻고 오류 메시지를 쉽게 분석할 수 있습니다.68

성능 튜닝은 단 한 번의 설정으로 끝나는 과정이 아니라, 벤치마킹, 튜닝, 진단을 반복하며 시스템에 가장 적합한 구성을 찾아가는 지속적인 엔지니어링 활동입니다.

3.3 안전 보장 시스템 구축: 기능 안전과 ISO 26262

자율주행차, 항공기, 의료 로봇과 같이 인간의 생명과 안전에 직결되는 시스템에서 소프트웨어의 오작동은 재앙적인 결과를 초래할 수 있습니다. 이러한 시스템을 ‘안전 필수(safety-critical)’ 시스템이라 하며, 이들을 개발할 때는 ’기능 안전(Functional Safety)’이라는 엄격한 공학적 원칙을 따라야 합니다. 이 장에서는 RTI Connext DDS가 어떻게 이러한 엄격한 안전 요구사항을 충족시키고, 특히 자동차 산업의 핵심 표준인 ISO 26262를 지원하는지 살펴봅니다.

3.3.1 기능 안전과 미들웨어의 역할

기능 안전은 시스템의 전기/전자 부품 오작동으로 인해 발생할 수 있는 불합리한 위험을 방지하는 것을 목표로 합니다. ISO 26262는 자동차 산업을 위해 특별히 제정된 기능 안전 국제 표준으로, 시스템, 하드웨어, 소프트웨어 개발의 전 과정에 걸쳐 따라야 할 요구사항과 프로세스를 정의합니다.69

이 표준은 위험 분석을 통해 **ASIL(Automotive Safety Integrity Level, 자동차 안전 무결성 수준)**이라는 위험 등급을 A(가장 낮음)부터 D(가장 높음)까지 부여합니다. 시스템의 각 안전 관련 기능은 할당된 ASIL 등급에 따라 정해진 수준의 엄격한 개발 및 검증 절차를 거쳐야 합니다.69

현대의 자동차는 수많은 전자제어장치(ECU)와 소프트웨어로 구성된 복잡한 분산 시스템입니다. 이들 간의 안정적이고 예측 가능한 통신은 기능 안전을 달성하는 데 있어 매우 중요합니다. 따라서 통신을 담당하는 미들웨어 역시 기능 안전 요구사항을 만족시켜야 합니다.

3.3.2 Connext DDS Cert와 ISO 26262

RTI는 이러한 안전 필수 시스템 시장의 요구에 부응하기 위해 Connext DDS Cert라는 특화된 제품을 제공합니다.28 이 제품은 ISO 26262 ASIL D와 같은 최고 수준의 안전 인증을 목표로 하는 시스템에 사용될 수 있도록 설계되었습니다. Connext DDS Cert는 단순히 소프트웨어 라이브러리만 제공하는 것이 아니라, 인증 기관에 제출해야 하는 방대한 양의 설계 문서, 테스트 결과, 분석 안내서 등 **인증 증거 자료(certification evidence)**를 함께 제공하여 고객의 인증 과정을 크게 단축하고 비용을 절감해줍니다.36

또한, 자동차 소프트웨어 플랫폼의 핵심 표준인 AUTOSAR는 DDS를 통신 미들웨어 중 하나로 채택하면서, DDS 구현체가 ISO 26262를 준수하는 종단간(End-to-End) 데이터 보호 메커니즘을 지원해야 한다고 명시하고 있습니다.72 이는 DDS가 자동차 산업의 기능 안전 생태계에서 핵심적인 역할을 수행하고 있음을 보여줍니다. eProsima의 Safe DDS와 같은 다른 벤더의 제품들도 ISO 26262 ASIL D 준수를 목표로 개발되고 있습니다.73

3.3.3 QoS를 이용한 안전 패턴 구현

Connext DDS의 놀라운 점은, 별도의 안전 메커니즘을 추가하는 것이 아니라 표준 DDS QoS 정책들을 조합하는 것만으로도 강력한 안전 패턴을 구현할 수 있다는 것입니다. 이는 DDS의 아키텍처 자체가 내결함성과 예측 가능성을 염두에 두고 설계되었기 때문입니다. [44]과 [44]은 자동차 시스템에서 이러한 패턴이 어떻게 구현되는지 구체적으로 설명합니다.

• 원활한 장애 극복 (Seamless Failover): 이 패턴은 주(primary) 컴포넌트가 아무런 경고 없이 조용히 실패(fail-silent)하는 상황에 대응합니다.
• 구현: 주 제어 채널의 DataWriter와 예비(redundant) 안전 채널의 DataWriter를 준비합니다. 주 DataWriter에 더 높은 OWNERSHIP_STRENGTH를, 예비 DataWriter에 더 낮은 strength를 부여하고, OWNERSHIP 정책은 EXCLUSIVE로 설정합니다. 또한 LIVELINESS 정책을 활성화합니다.
• 동작: 평상시에는 높은 strength를 가진 주 DataWriter가 데이터 인스턴스의 소유권을 가지고 데이터를 발행합니다. 만약 주 DataWriter가 다운되거나 네트워크 연결이 끊겨 LIVELINESS를 잃게 되면, DDS 미들웨어는 이를 즉시 감지하고 소유권을 다음으로 strength가 높은 예비 DataWriter에게 자동으로 넘겨줍니다. 차량 액추에이터는 이제 예비 채널의 데이터를 수신하여 중단 없이 안전한 상태로 차량을 제어할 수 있습니다.
• 원활한 인계 (Seamless Takeover): 이 패턴은 고장 난 컴포넌트가 멈추지 않고, 오히려 잘못된 데이터를 계속해서 발행하는 더 위험한 상황에 대응합니다.
• 구현: EXCLUSIVE OWNERSHIP과 OWNERSHIP_STRENGTH 정책을 사용합니다. 시스템에는 별도의 ‘안전 감시자(safety checker)’ 노드가 존재합니다.
• 동작: 안전 감시자는 주 DataWriter가 발행하는 데이터를 모니터링합니다. 만약 데이터가 허용 범위를 벗어나거나, DEADLINE QoS를 위반하여 제때 데이터를 발행하지 못하는 등 비정상적인 동작을 감지하면, 안전 감시자는 즉시 주 DataWriter보다 더 높은 OWNERSHIP_STRENGTH를 가진 건강한(healthy) DataWriter를 활성화시킵니다. 이 새로운 DataWriter는 즉시 데이터 인스턴스의 소유권을 ’인계(takeover)’받아 올바른 제어 값을 발행하기 시작하여, 오작동하는 컴포넌트의 영향을 차단합니다.
• 하이브리드 접근 방식: Deadline, Liveliness, Ownership QoS 정책들을 모두 조합하면 더욱 정교한 안전 메커니즘을 구축할 수 있습니다. 안전 감시자는 Liveliness 상태를 모니터링하여 ‘조용한 실패’ 시에는 장애 극복(failover)을, Deadline 위반이나 데이터 이상 감지 시에는 인계(takeover)를 유연하게 트리거할 수 있습니다.

이처럼 DDS는 단순한 통신 프로토콜을 넘어, 견고하고 고장 방지 기능이 내장된 시스템 아키텍처를 구축하기 위한 강력한 프레임워크입니다. QoS 정책을 통해 복잡한 안전 로직을 선언적으로 구현할 수 있는 능력은, DDS가 왜 자동차, 항공, 국방과 같은 안전 필수 산업에서 신뢰받는 기술로 자리 잡았는지를 명확히 보여줍니다. 아키텍트의 관점에서 이는 직접 안전 로직을 개발하고 인증받는 데 드는 막대한 비용과 위험을 줄여주는 결정적인 이점입니다.

4. 광범위한 생태계와 경쟁 환경

RTI Connext DDS의 기술적 깊이를 이해했다면, 이제는 시야를 넓혀 이 기술이 실제 산업 현장에서 어떻게 사용되고, 다른 기술들과 비교하여 어떤 위치에 있으며, 주요 개발 프레임워크와 어떻게 통합되는지 살펴볼 차례입니다. 이 파트는 아키텍트와 의사결정자가 Connext DDS를 전략적인 관점에서 평가하고, 자신의 프로젝트에 적합한지 판단하는 데 필요한 거시적인 시각을 제공합니다.

4.1 Connext DDS 실제 적용 사례: 산업별 사용 사례 조사

Connext DDS는 이론적인 기술이 아니라, 전 세계 수많은 미션 크리티컬 시스템의 심장부에서 활약하고 있는 검증된 기술입니다. 다양한 산업 분야에서의 성공적인 적용 사례는 DDS의 유연성과 강력함을 증명합니다.

4.1.1 자동차: 소프트웨어 정의 차량(SDV)

현대 자동차는 ’바퀴 달린 데이터 센터’로 진화하고 있으며, DDS는 이러한 소프트웨어 정의 차량(SDV)의 핵심 신경망 역할을 합니다.

• E/E 아키텍처의 근간: DDS는 최신 차량의 전기/전자(E/E) 아키텍처에서 분산된 ECU, 고성능 컴퓨팅 유닛, 그리고 라이다(LIDAR), 레이더, 카메라와 같은 수많은 센서들을 연결하는 데이터버스로 기능합니다.8 이를 통해 첨단 운전자 보조 시스템(ADAS)과 완전 자율주행 시스템에 필요한 방대한 양의 데이터를 실시간으로 공유하고 처리합니다.36
• Zonal 아키텍처와 TSN: 차량을 기능별 구역(Zone)으로 나누는 Zonal 아키텍처에서 DDS는 각 구역 간의 데이터 흐름을 관리합니다. 특히, 이더넷 기반의 시분할 민감 네트워킹(Time-Sensitive Networking, TSN) 기술과 결합될 때, DDS는 예측 가능하고 결정적인(deterministic) 통신을 보장하여 안전 필수 기능의 신뢰성을 극대화합니다.75
• 실제 적용 사례: 폭스바겐(Volkswagen)은 운전자 보조 기능과 통합 안전 시스템에 Connext DDS를 사용하여 장애물 회피, 차선 이탈 감지 등을 구현했으며, 중국의 전기차 스타트업인 리오토(Li Auto) 역시 지능형 차량 시스템의 복잡한 통신 문제를 해결하기 위해 Connext Drive를 채택했습니다.36

4.1.2 항공우주 및 국방

가장 높은 수준의 신뢰성과 보안이 요구되는 항공우주 및 국방 분야는 DDS 기술이 가장 먼저, 그리고 가장 깊숙이 뿌리내린 영역입니다.

• 미션 크리티컬 시스템: 미 해군 함정의 전투 관리 시스템, 무인 항공기(UAV) 및 지상 차량의 제어 시스템 등 수백 개의 국방 프로그램이 DDS를 통신 백본으로 사용하고 있습니다.10
• FACE™ 표준: 미군 항공 시스템의 상호운용성과 재사용성을 높이기 위한 개방형 아키텍처 표준인 FACE™(Future Airborne Capability Environment)는 DDS를 전송 서비스 세그먼트(Transport Services Segment)의 핵심 표준 중 하나로 채택하고 있습니다.24 이는 DDS가 국방 항공 분야의 표준 기술로 확고히 자리 잡았음을 의미합니다.

4.1.3 산업용 IoT(IIoT) 및 로보틱스

스마트 팩토리, 에너지, 로보틱스 분야에서도 DDS는 시스템의 지능화와 자동화를 이끄는 핵심 기술로 활약하고 있습니다.

• 산업 자동화 및 에너지: 스마트 공장의 자동화 라인, 풍력/수력 발전소의 분산 제어 시스템, 스마트 그리드 등에서 대규모의 센서 데이터와 제어 명령을 안정적으로 교환하는 데 사용됩니다.9
• ROS 2와 로보틱스: 로봇 개발을 위한 세계 최고의 오픈소스 프레임워크인 **ROS 2(Robot Operating System 2)**는 통신 미들웨어로 DDS를 기본 채택했습니다.8 이는 로보틱스 분야에서 DDS가 사실상의 표준(de facto standard)임을 의미하며, 수많은 로봇 애플리케이션이 DDS 위에서 개발되고 있습니다.81

4.1.4 헬스케어

의료 분야에서 DDS는 환자의 안전을 개선하고 의료 서비스의 효율성을 높이는 데 기여하고 있습니다.

• 의료기기 상호운용성: 수술실이나 중환자실(ICU)에 있는 다양한 제조사의 의료기기들(환자 감시 장치, 인공호흡기, 주입 펌프 등)을 서로 연결하여 데이터를 통합하고, 이를 통해 의료진에게 종합적인 환자 상태 정보를 제공합니다.39 미국 FDA와 같은 규제 기관도 이러한 의료기기 상호운용성 이니셔티브를 적극 지지하고 있습니다.82
• 의료 영상 및 로봇: MRI, CT와 같은 고성능 의료 영상 장비 내부의 분산 제어 및 데이터 수집, 그리고 수술 로봇의 정밀한 실시간 제어에도 Connext DDS가 사용됩니다.29

이처럼 RTI Connext DDS는 다양한 산업 분야에서 가장 까다로운 기술적 과제들을 해결하며 그 가치를 입증하고 있습니다.

4.2 비교 분석: DDS 대안 프로토콜과의 비교

시스템 아키텍트는 자신이 선택한 기술뿐만 아니라, 그 대안이 될 수 있는 다른 기술들의 장단점을 명확히 이해하고 있어야 합니다. 이를 통해 기술 선택의 타당성을 입증하고, 특정 문제에 가장 적합한 도구를 선택할 수 있습니다. 이 장에서는 DDS를 널리 사용되는 다른 통신 프로토콜들과 비교 분석합니다.

4.2.1 DDS 대 MQTT

IoT 시스템에서 가장 자주 비교되는 두 프로토콜입니다. 둘 다 발행-구독 모델을 사용하지만, 그 철학과 아키텍처는 근본적으로 다릅니다. 4의 분석을 기반으로 다음과 같이 비교할 수 있습니다.

• 아키텍처: DDS는 중앙 브로커가 없는 P2P 방식인 반면, MQTT는 중앙 브로커를 반드시 거쳐야 하는 허브-앤-스포크 방식입니다.5 DDS는 단일 장애점이 없고 지연 시간이 짧지만, MQTT는 브로커가 병목이 될 수 있습니다.
• 데이터 모델: DDS는 미들웨어가 데이터의 구조를 이해하는 ’데이터 중심’입니다. 이를 통해 풍부한 QoS와 내용 기반 필터링이 가능합니다. 반면 MQTT는 데이터 내용을 모르는 ’메시지 중심’으로, 단순한 토픽 기반의 라우팅만 제공합니다.4
• 성능: DDS는 고처리량, 저지연, 실시간 제어에 최적화되어 있습니다. MQTT는 저대역폭, 고지연, 비신뢰성 네트워크 환경에서의 경량 통신에 최적화되어 있습니다.4
• 이상적인 사용 사례: DDS는 자율주행차, 공장 자동화, 전투 시스템과 같이 엣지에서의 실시간 제어와 데이터 공유에 적합합니다. MQTT는 수많은 저사양 센서로부터 데이터를 수집하여 클라우드로 전송하는 원격 측정(telemetry) 시나리오에 이상적입니다.4

4.2.2 DDS 대 REST API

• 통신 패턴: DDS는 지속적인 데이터 스트림을 위한 발행-구독(Pub/Sub) 모델입니다. REST는 일회성 상호작용을 위한 클라이언트-서버 요청-응답(Request-Response) 모델입니다.2
• 상태 관리: DDS 미들웨어는 데이터의 최신 상태를 캐시에 유지하는 상태 저장(stateful) 방식입니다. REST는 각 요청이 독립적으로 처리되는 무상태(stateless) 방식입니다.1
• 사용 사례: DDS는 실시간으로 변화하는 상태를 다수의 참여자에게 지속적으로 공유하는 데 사용됩니다. REST는 특정 리소스에 대한 생성, 조회, 수정, 삭제(CRUD)와 같은 트랜잭션 기반의 일대일 상호작용에 적합합니다.6

4.2.3 DDS 대 gRPC

• 통신 패턴: DDS는 데이터 중심의 Pub/Sub 모델인 반면, gRPC는 서비스 중심의 RPC 모델입니다.2
• 결합도: DDS는 발행자와 구독자를 완전히 분리하여 극도의 느슨한 결합을 제공합니다. gRPC는 클라이언트가 특정 서비스의 특정 함수를 호출해야 하므로 더 강한 결합을 가집니다.
• 사용 사례: DDS는 다수의 시스템이 비동기적으로 데이터를 공유하는 다대다(many-to-many) 분산 환경에 탁월합니다. gRPC는 고성능의 클라이언트-서버 통신, 특히 마이크로서비스 간의 효율적인 API 호출에 뛰어납니다.3

4.2.4 RTI Connext 대 다른 DDS 벤더

DDS는 표준이므로 여러 벤더가 구현체를 제공합니다. RTI Connext 외의 주요 벤더는 다음과 같습니다.

• eProsima Fast DDS: Apache 2.0 라이선스의 오픈소스로, ROS 2의 기본 미들웨어로 채택되어 있습니다. 경량이며 특히 비동기 발행 모드에서 우수한 성능을 보이는 것으로 알려져 있습니다.8
• Eclipse Cyclone DDS / ADLINK Vortex OpenSplice: Eclipse 재단에서 관리하는 또 다른 주요 오픈소스 및 상용 DDS 구현체입니다. 과거에는 공유 메모리 기반의 데몬(daemon)을 사용하는 독특한 아키텍처를 가졌으나, 점차 다른 구현체들과 유사한 방식으로 발전해왔습니다.17

RTPS 와이어 프로토콜 표준 덕분에 이들 벤더 간의 기본적인 데이터 교환은 보장됩니다. 하지만 공유 메모리 전송과 같은 벤더 고유의 최적화 기능이나 고급 QoS 정책의 해석 방식, 그리고 개발 도구의 성숙도 등에서는 차이가 있을 수 있습니다.91 RTI Connext는 특히 풍부한 개발 및 분석 도구, 상세한 문서, 전문적인 기술 지원, 그리고 안전 필수 시스템을 위한 인증 지원 측면에서 강점을 가지는 것으로 평가받습니다.89

아래 표는 주요 통신 프로토콜의 특성을 한눈에 비교하여 아키텍트의 기술 선택을 돕습니다. 이 표는 “어떤 기술이 더 좋은가?“가 아니라 “어떤 문제가 주어졌을 때 어떤 기술이 가장 적합한가?“라는 질문에 답하는 데 중점을 둡니다.

4.3 주요 프레임워크와의 통합: ROS 2와 Simulink

RTI Connext DDS는 독립적인 기술로도 강력하지만, 로보틱스와 제어 시스템 설계 분야의 두 거대 프레임워크인 ROS 2와 Simulink와의 긴밀한 통합을 통해 그 생태계를 더욱 확장하고 있습니다. 이러한 통합은 각 프레임워크 사용자들이 DDS의 강력한 실시간 통신 기능을 자신들의 익숙한 개발 환경에서 원활하게 활용할 수 있도록 셔틀 역할을 합니다.

4.3.1 ROS 2: 로봇 운영체제

ROS(Robot Operating System)는 로봇 소프트웨어 개발을 위한 사실상의 표준 프레임워크입니다. 그 차세대 버전인 ROS 2는 아키텍처의 근본적인 변화를 꾀했는데, 그중 가장 중요한 것이 바로 통신 미들웨어로 DDS를 채택한 것입니다.80

• RMW(ROS Middleware) 계층: ROS 1의 자체 통신 프로토콜(TCPROS/UDPROS)은 확장성과 실시간성에 한계가 있었습니다. ROS 2는 이를 해결하기 위해 DDS를 통신 백본으로 사용하기로 결정했습니다. 하지만 특정 DDS 벤더에 종속되는 것을 피하기 위해, ROS 2는 **RMW(ROS Middleware Interface)**라는 추상화 계층을 도입했습니다.93 RMW는 ROS 2의 상위 클라이언트 라이브러리(rclcpp, rclpy 등)와 하위의 실제 DDS 구현체 사이의 ‘어댑터’ 역할을 합니다.
• RTI Connext 지원: 개발자는 이 RMW 계층 덕분에 원하는 DDS 구현체를 선택하여 사용할 수 있습니다. RTI Connext는 eProsima Fast DDS, Eclipse Cyclone DDS와 함께 ROS 2에서 완벽하게 지원되는 최상위(Tier 1) RMW 구현체 중 하나입니다.8 이는 ROS 2로 개발된 시스템을 상용화하거나, 고도의 신뢰성 및 보안이 요구되는 미션 크리티컬 애플리케이션에 적용하고자 할 때, 검증된 상용 솔루션인 RTI Connext를 선택할 수 있음을 의미합니다. ROS 2 사용자는 익숙한 ROS 2의 토픽, 서비스, 액션 API를 그대로 사용하면서, 그 내부적으로는 Connext DDS의 강력한 성능과 QoS 기능을 활용할 수 있습니다.

4.3.2 MathWorks Simulink: 모델 기반 설계

Simulink는 제어 시스템, 신호 처리, 동적 시스템 시뮬레이션을 위한 모델 기반 설계(Model-Based Design, MBD) 환경으로, 특히 자동차 및 항공우주 산업에서 널리 사용됩니다. MathWorks는 DDS와의 통합을 위해 DDS Blockset을 제공합니다.

• DDS Blockset과의 통합: DDS Blockset은 Simulink 모델이 DDS 네트워크에 직접 참여하여 데이터를 발행하고 구독할 수 있도록 해주는 앱과 블록들의 모음입니다.97 RTI Connext는 DDS Blockset에서 공식적으로 지원하는 주요 DDS 벤더 중 하나입니다.99
• 모델 기반 개발 워크플로우: 개발자는 다음과 같은 워크플로우를 통해 Simulink 환경에서 DDS 애플리케이션을 설계, 시뮬레이션, 배포할 수 있습니다.

1. 정의 가져오기: IDL 또는 XML 파일에 정의된 DDS 데이터 타입, 토픽, QoS 프로파일을 Simulink의 ’DDS Dictionary’로 가져옵니다.100
2. 모델링: Simulink 캔버스에 ‘Publish’, ‘Subscribe’ 블록을 배치하고, 이를 제어 알고리즘 블록과 연결하여 전체 애플리케이션 로직을 그래픽하게 모델링합니다.101
3. 시뮬레이션: 실제 하드웨어나 코드를 생성하기 전에, Simulink 환경 내에서 전체 시스템의 동작을 시뮬레이션하여 알고리즘을 검증하고 QoS 설정을 튜닝할 수 있습니다.
4. 코드 생성 및 배포: Embedded Coder를 사용하여 완성된 Simulink 모델로부터 C++ 애플리케이션 코드와 DDS 구성을 위한 XML 파일을 자동으로 생성할 수 있습니다.97 이 생성된 코드는 실제 타겟 하드웨어에 배포되어 독립적인 DDS 애플리케이션으로 실행됩니다.

RTI는 MathWorks 사용자를 위해 전용 라이선스 프로그램과 기술 지원을 제공하여 99, 모델 기반 설계를 통해 개발된 정교한 제어 시스템이 Connext DDS의 강력한 실시간 데이터버스와 원활하게 통합될 수 있도록 지원합니다. 이는 복잡한 시스템의 개발 생산성과 신뢰성을 크게 향상시키는 강력한 조합입니다.

5. 개발자를 위한 실용 가이드

지금까지 DDS의 이론적 배경, RTI Connext의 기능, 그리고 실제 산업 적용 사례까지 폭넓게 살펴보았습니다. 마지막 파트에서는 이론을 넘어, DDS를 처음 접하는 개발자가 실제로 기술을 사용해보고 일반적인 문제에 부딪혔을 때 해결할 수 있도록 돕는 실용적인 가이드를 제공합니다. 이 장들은 신규 사용자의 학습 곡선을 완만하게 만들고, DDS 개발의 초기 장벽을 낮추는 것을 목표로 합니다.

5.1 제로에서 데이터버스까지: 개발자 빠른 시작 가이드

복잡한 기술을 배울 때 가장 좋은 방법은 직접 사용해보는 것입니다. 이 장에서는 코딩 없이 DDS의 핵심 개념을 시각적으로 체험하는 것부터 간단한 애플리케이션을 직접 빌드하는 과정까지, 새로운 사용자를 위한 단계별 온보딩 경로를 제시합니다.

5.1.1 RTI Shapes Demo를 이용한 개념 시각화

RTI Shapes Demo는 코딩 한 줄 없이 DDS의 핵심 개념을 직관적으로 이해할 수 있도록 설계된 강력한 그래픽 도구입니다.102 사용자는 여러 개의 Shapes Demo 창을 띄워놓고, 각 창에서 도형(Square, Circle, Triangle)을 발행하거나 구독하는 것만으로 복잡한 분산 시스템의 동작을 시뮬레이션할 수 있습니다.

• 기본 발행-구독 체험:

1. 첫 번째 Shapes Demo 창에서 ‘Publish’ 메뉴의 ’Square’를 클릭하여 파란색 사각형을 발행합니다.102
2. 두 번째 창에서 ‘Subscribe’ 메뉴의 ’Square’를 클릭합니다.
3. 즉시 두 번째 창에 첫 번째 창의 파란색 사각형이 나타나 움직이는 것을 볼 수 있습니다. 이는 중앙 서버 없이 두 애플리케이션이 서로를 자동으로 발견(auto-discovery)하고 P2P로 데이터를 교환하는 DDS의 기본 동작을 보여줍니다.

• QoS 개념 이해:
• History: 구독 창의 도형은 희미한 잔상(History)을 남기며 움직입니다. ‘Controls’ 메뉴에서 History QoS 설정을 변경하여 이 잔상의 길이를 조절하거나 없앨 수 있습니다.102
• Partition: 발행 및 구독 시 ‘Partition’ 이름을 지정하여, 동일한 토픽이라도 특정 파티션에 속한 애플리케이션끼리만 통신하도록 만들 수 있습니다. 이를 통해 데이터 흐름을 어떻게 격리하는지 시각적으로 확인할 수 있습니다.51
• Reliability: QoS 설정에서 신뢰성을 RELIABLE과 BEST_EFFORT로 변경하며 통신이 어떻게 달라지는지 실험해볼 수 있습니다.

Shapes Demo는 DDS의 동적이고 데이터 중심적인 특성을 눈으로 직접 확인시켜 줌으로써, 추상적인 개념을 구체적인 경험으로 바꾸어주는 최고의 학습 도구입니다.

5.1.2 첫 애플리케이션 빌드하기

개념을 이해했다면, 이제 간단한 코드를 작성해볼 차례입니다. RTI는 GitHub를 통해 단계별 “Getting Started” 예제를 제공하여 신규 개발자가 쉽게 따라 할 수 있도록 돕습니다.104 “초콜릿 공장(Chocolate Factory)“이라는 시나리오를 바탕으로 한 이 예제들은 DDS 애플리케이션 개발의 전형적인 워크플로우를 안내합니다.

1. 데이터 타입 정의 (IDL): 통신에 사용할 데이터 구조를 IDL 파일에 정의합니다.
2. 코드 생성: RTI 코드 생성기(rtiddsgen)를 실행하여 IDL 파일로부터 특정 프로그래밍 언어(C++, Java 등)의 소스 코드를 생성합니다.
3. 애플리케이션 로직 작성: 생성된 코드를 사용하여 DomainParticipant, Publisher, Subscriber, DataWriter, DataReader 등의 DDS 엔티티를 생성하고, 데이터를 write()하거나 read()/take()하는 애플리케이션 로직을 구현합니다.
4. 컴파일 및 실행: 애플리케이션을 컴파일하고, 발행자(publisher)와 구독자(subscriber)를 각각 실행하여 데이터가 교환되는 것을 확인합니다.

이 과정을 통해 개발자는 DDS API의 기본적인 사용법을 익히고, 자신의 개발 환경을 설정하는 방법을 배울 수 있습니다.

5.1.3 라이선스 및 커뮤니티

• 라이선스 모델: RTI Connext는 다양한 라이선스 모델을 제공합니다. 상용 프로젝트를 위한 상용 라이선스, 대학이나 연구 기관을 위한 연구/학술용 라이선스, 그리고 비상업적 목적의 개발 및 학습을 위한 무료 ‘커뮤니티’ 소스 라이선스 등이 있습니다.105 이를 통해 사용자는 자신의 목적에 맞는 라이선스를 선택할 수 있습니다.
• RTI 커뮤니티 포럼: 개발 과정에서 문제에 부딪히거나 질문이 생겼을 때, RTI 커뮤니티 포럼은 매우 유용한 자원입니다.108 전 세계의 다른 DDS 사용자와 RTI 엔지니어들이 활동하는 이 포럼에서 질문을 올리고 답변을 얻거나, 기존의 논의들을 검색하여 문제 해결의 힌트를 얻을 수 있습니다.

5.2 일반적인 과제와 문제 해결

모든 복잡한 기술에는 학습 곡선이 따르며, DDS도 예외는 아닙니다. 특히 분산 시스템의 특성상 문제의 원인이 다양하고 복잡할 수 있습니다. 이 장에서는 신규 사용자들이 가장 흔하게 겪는 문제들을 식별하고, 이를 해결하기 위한 체계적인 접근법과 유용한 도구들을 소개합니다.

5.2.1 “왜 내 애플리케이션들이 서로를 보지 못할까?” - 검색 문제 해결

DDS를 처음 사용할 때 가장 빈번하게 마주치는 문제는 “발행자는 데이터를 보내고 있는데, 왜 구독자가 아무것도 받지 못하는가?“입니다. 이는 대부분 참여자 간의 ‘검색(Discovery)’ 과정이 실패했기 때문입니다. 109와 [110]의 내용을 바탕으로 다음과 같은 체크리스트를 통해 문제의 원인을 체계적으로 점검할 수 있습니다.

1. 방화벽(Firewall): 가장 흔한 원인입니다. DDS는 기본적으로 UDP/멀티캐스트를 사용하여 검색 정보를 교환합니다. PC의 운영체제 방화벽이나 네트워크 장비(라우터, 스위치)가 이 UDP 트래픽, 특히 멀티캐스트 패킷을 차단하고 있는지 확인해야 합니다. DDS가 사용하는 포트(기본적으로 도메인 ID에 따라 계산됨)를 방화벽에서 허용해야 합니다.
2. 네트워크 구성:

• 멀티캐스트 지원 여부: 사용 중인 네트워크(특히 Wi-Fi나 복잡한 기업 네트워크)가 멀티캐스트를 지원하지 않을 수 있습니다. 멀티캐스트가 동작하지 않으면, 서로 다른 머신에 있는 참여자들은 서로를 발견할 수 없습니다.
• 유니캐스트로 전환 (initial_peers): 멀티캐스트를 사용할 수 없는 환경이라면, 유니캐스트를 사용하도록 명시적으로 설정해야 합니다. NDDS_DISCOVERY_PEERS 환경 변수나 XML QoS 파일의 <initial_peers> 태그에 상대방 참여자의 IP 주소를 직접 지정해주면, 멀티캐스트 없이도 검색이 가능합니다.111

3. DDS 구성 불일치:

• 도메인 ID (Domain ID): 통신하려는 모든 DomainParticipant가 반드시 동일한 도메인 ID를 사용하고 있는지 확인해야 합니다. ID가 다르면 완전히 다른 가상 네트워크에 있는 것과 같습니다.
• 토픽 이름 및 타입: 발행자와 구독자가 정확히 동일한 토픽 이름과 호환되는 데이터 타입을 사용하고 있는지 확인해야 합니다. 대소문자나 오타 하나만으로도 매칭은 실패합니다.
• 파티션 (Partition): 만약 Partition QoS를 사용하고 있다면, 발행자와 구독자가 최소 하나 이상의 공통된 파티션 이름을 가지고 있는지 확인해야 합니다.

4. QoS 호환성:

• 앞서 설명한 ‘요청 대 제공’ 모델에 따라, DataWriter와 DataReader의 QoS 정책이 서로 호환되지 않으면 연결이 성립되지 않습니다. 예를 들어, DataReader가 RELIABLE을 요청하는데 DataWriter가 BEST_EFFORT를 제공하는 경우가 대표적입니다.

5.2.2 RTI 도구를 이용한 디버깅

문제의 원인을 진단할 때, RTI가 제공하는 강력한 도구들을 활용하면 시간과 노력을 크게 절약할 수 있습니다.

• RTI Admin Console / Monitor: 이 그래픽 도구는 실행 중인 데이터버스의 ’지도’와 같습니다.65 어떤 참여자들이 어떤 토픽을 발행/구독하고 있는지, 그들의 QoS 설정은 무엇인지, 그리고 성공적으로 매칭되었는지 여부를 시각적으로 보여줍니다. 특히 ‘Match Analysis’ 기능은 QoS 불일치로 인해 매칭이 실패했을 때, 어떤 정책이 문제인지 정확히 알려주어 디버깅에 결정적인 단서를 제공합니다.68

• 로깅 및 RTI Log Parser: 애플리케이션에서 DDS 로깅을 활성화하면 미들웨어 내부 동작에 대한 상세한 로그를 얻을 수 있습니다. 하지만 이 로그는 양이 방대하고 해석하기 어려울 수 있습니다. RTI Log Parser는 이 원시 로그를 입력받아, 시간 순서에 따라 이벤트(예: 패킷 수신, 누락, 재전송 요청 등)를 보기 쉽게 재구성하고 분석해주는 커맨드라인 도구입니다. 이를 통해 네트워크 수준의 문제를 깊이 있게 파악할 수 있습니다.68

• RTI Perftest: 애플리케이션 코드에 문제가 있는지, 아니면 네트워크나 DDS 구성 자체에 문제가 있는지 분리하여 테스트하고 싶을 때 사용하는 도구입니다.66

rtiperftest를 발행자와 구독자 머신에서 각각 실행하여 기본적인 데이터 통신이 이루어지는지 먼저 확인합니다. 만약 rtiperftest는 통신이 되는데 내 애플리케이션은 안 된다면, 문제는 애플리케이션 코드나 QoS 설정에 있을 가능성이 높습니다. 만약 rtiperftest조차 통신이 안 된다면, 방화벽이나 네트워크 설정과 같은 더 근본적인 문제를 먼저 해결해야 합니다.109

이러한 체계적인 문제 해결 접근법과 강력한 디버깅 도구들은 개발자가 DDS 시스템을 구축하고 운영하면서 마주치는 불가피한 문제들을 효율적으로 해결하고, 시스템의 안정성을 확보하는 데 큰 도움이 될 것입니다.

5.3 결론: 데이터 중심 아키텍처의 전략적 가치

이 안내서는 RTI Connext DDS를 처음 접하는 기술 전문가를 위해, 그 근간을 이루는 데이터 중심 철학부터 핵심 아키텍처, 고급 기능, 그리고 실제 산업 적용 사례에 이르기까지 포괄적인 분석을 제공했습니다. 분석을 통해 드러난 RTI Connext DDS의 본질은 단순히 또 하나의 메시징 라이브러리가 아니라, 확장 가능하고 신뢰성 높으며 안전한 실시간 분산 시스템을 구축하기 위한 포괄적인 소프트웨어 프레임워크라는 점입니다.

DDS가 제시하는 패러다임의 전환은 명확합니다. 통신의 복잡성을 애플리케이션 개발자의 어깨에서 덜어내어, 고도로 최적화되고 표준화된 미들웨어 계층으로 이전시키는 것입니다. 이는 다음과 같은 전략적 가치를 창출합니다.

• 개발 생산성 향상 및 비용 절감: 데이터 중심 아키텍처와 풍부한 QoS 정책은 복잡한 통신 로직(예: 동적 검색, 상태 관리, 장애 극복, 데이터 필터링)을 애플리케이션 코드에서 분리해냅니다. 이를 통해 개발자는 핵심 비즈니스 로직에 집중할 수 있으며, 이는 개발 시간 단축, 테스트 부담 감소, 그리고 장기적인 유지보수 비용 절감으로 이어집니다.
• 시스템 견고성 및 신뢰성 극대화: 브로커 없는 P2P 아키텍처는 단일 장애점을 원천적으로 제거합니다. 여기에 Ownership, Liveliness, Deadline과 같은 QoS 정책을 조합하면, 미션 크리티컬 시스템이 요구하는 정교한 고가용성 및 내결함성 메커니즘을 선언적으로 구현할 수 있습니다. 이는 수많은 실제 시스템에서 검증된 강력한 아키텍처 패턴입니다.
• 상호운용성 및 확장성 보장: DDSI-RTPS라는 표준 와이어 프로토콜은 서로 다른 벤더의 구현체, 다른 프로그래밍 언어, 다른 운영체제로 개발된 시스템 컴포넌트들이 원활하게 상호작용할 수 있도록 보장합니다. 이는 특정 기술에 대한 종속성을 줄이고, 시스템을 점진적으로 확장하고 진화시킬 수 있는 유연한 기반을 제공합니다.

물론, RTI Connext DDS를 채택하는 것은 전략적인 아키텍처 결정입니다. 그 강력함을 온전히 활용하기 위해서는 데이터 중심 원칙과 데이터 모델링 모범 사례에 대한 초기 학습 투자가 필요합니다. 그러나 자율 시스템, 지능형 의료기기, 차세대 국방 시스템, 스마트 인프라와 같이 점점 더 복잡해지고 서로 연결되는 현대 시스템의 요구사항을 고려할 때, 이러한 투자는 단순한 비용이 아니라 미래를 위한 현명한 투자입니다.

결론적으로, RTI Connext DDS는 차세대 지능형, 자율형, 미션 크리티컬 시스템을 구축하고자 하는 조직에게, 시스템의 복잡성을 관리하고, 신뢰성을 확보하며, 장기적인 유지보수성과 진화 가능성을 보장하는 가장 성숙하고 강력한 솔루션 중 하나를 제공합니다. 이는 단순한 기술 선택을 넘어, 성공적인 시스템 아키텍처를 위한 전략적 기반을 마련하는 것입니다.

6. 참고 자료

1. REST vs CRUD: Key concepts and differences - LogicMonitor, accessed July 1, 2025, https://www.logicmonitor.com/blog/rest-vs-crud

2. What’s the difference between DDS and SOME/IP? - Stack Overflow, accessed July 1, 2025, https://stackoverflow.com/questions/51182471/whats-the-difference-between-dds-and-some-ip

3. A communications backbone for the autonomous battlespace …, accessed July 1, 2025, https://defencex.ai/wordpress/a-communications-backbone-for-the-autonomous-battlespace/

4. Navigating IIoT Protocols: Comparing DDS and MQTT, accessed July 1, 2025, https://www.rti.com/blog/comparing-dds-and-mqtt

5. MQTT and DDS: Machine to Machine Communication in IoT - Real-Time Innovations, accessed July 1, 2025, https://www.rti.com/blog/mqtt-dds-m2m-protocol-internet-of-things/

6. DDS and MQTT: Basics, Challenges and Integration Benefits | EMQ - EMQX, accessed July 1, 2025, https://www.emqx.com/en/blog/navigating-dds-basics-limitations-and-integration-with-mqtt

7. Architectural Overview and OMG Data-Distribution Service - velog, accessed July 1, 2025, https://velog.io/@protocol5/ROS2OMG-Data-Distribution-Service-Architectural-Overview-and-OMG-Data-Distribution-Service-Architectural-Update

8. DDS(Data Distribution Service) 이해하기 - Hoon’s Blog - 티스토리, accessed July 1, 2025, https://yhoons.tistory.com/m/117

9. Connext DDS and the Industrial IoT: The Top 5 Things to Know - RTI, accessed July 1, 2025, https://www.rti.com/blog/connext-dds-and-the-industrial-iot-the-top-5-things-to-know

10. Data-centric architectural best practices: Using DDS to integrate real …, accessed July 1, 2025, https://militaryembedded.com/comms/communications/data-centric-real-world-distributed-systems

11. 데이터 분산 서비스 - 위키백과, 우리 모두의 백과사전, accessed July 1, 2025, https://ko.wikipedia.org/wiki/%EB%8D%B0%EC%9D%B4%ED%84%B0_%EB%B6%84%EC%82%B0_%EC%84%9C%EB%B9%84%EC%8A%A4

12. Data-Centric Programming Best Practices: - RTI, accessed July 1, 2025, https://www.rti.com/hubfs/docs/DDS_Best_Practices_WP.pdf

13. DDS 보안기술 - 한국전자통신연구원, accessed July 1, 2025, https://ettrends.etri.re.kr/ettrends/131/0905001659/26-5_112-122.pdf

14. ko.wikipedia.org, accessed July 1, 2025, https://ko.wikipedia.org/wiki/%EB%8D%B0%EC%9D%B4%ED%84%B0_%EB%B6%84%EC%82%B0_%EC%84%9C%EB%B9%84%EC%8A%A4#:~:text=%ED%95%A0%20%EC%88%98%20%EC%9E%88%EB%8B%A4.-,DDS%20%EB%AA%A8%EB%8D%B8,%EA%B5%AC%EB%8F%85%20%EB%AA%A8%EB%8D%B8%EC%9D%84%20%EA%B5%AC%ED%98%84%ED%96%88%EB%8B%A4.

15. How DDS simplifies multi - ECU E/E architectures | TTTech Auto, accessed July 1, 2025, https://www.tttech-auto.com/knowledge-platform/how-dds-simplifies-multi-ecu-ee-architectures

16. About the Data Distribution Service Specification Version 1.4 - Object Management Group, accessed July 1, 2025, https://www.omg.org/spec/DDS/1.4/About-DDS

17. Vortex OpenSplice Core – DCPS 및 DDSI2 - ADLINK Technology, accessed July 1, 2025, https://cdn.adlinktech.com/webupd/en/Upload/data-distribution-service/Vortex_OSPL_Core-Korean-0408.pdf

18. DDS(Data Distribution Service)란 무엇인가? - Perbiz, accessed July 1, 2025, http://perbiz.co.kr/data/DDS(Data%20Distribution%20Service)%EB%9E%80.pdf

19. Architecture of DDS When we create a DCPS DDS application, the… | Download Scientific Diagram - ResearchGate, accessed July 1, 2025, https://www.researchgate.net/figure/Architecture-of-DDS-When-we-create-a-DCPS-DDS-application-the-following-DDS-entities-are_fig2_267846873

20. Lab Note - 티스토리, accessed July 1, 2025, https://lab-notes.tistory.com/

21. RTI® Connext™ DDS-Comprehensive Summary of QoS Policies, accessed July 1, 2025, https://community.rti.com/static/documentation/connext-dds/5.2.0/doc/manuals/connext_dds/RTI_ConnextDDS_CoreLibraries_QoS_Reference_Guide.pdf

22. Introduction to DDS - OpenDDS 3.28.0, accessed July 1, 2025, https://opendds.readthedocs.io/en/dds-3.28/devguide/introduction_to_dds.html

23. DDS와 RTPS 개념정리 - Lab Note - 티스토리, accessed July 1, 2025, https://lab-notes.tistory.com/entry/DDS-DDS%EC%99%80-RTPS-%EA%B0%9C%EB%85%90%EC%A0%95%EB%A6%AC

24. Data Distribution Service for Complex Systems | DDS Standard | RTI, accessed July 1, 2025, https://www.rti.com/products/dds-standard

25. Introduction to DDS - eProsima, accessed July 1, 2025, https://www.eprosima.com/developer-resources/whitepapers/dds

26. Real-time Publish-Subscribe (RTPS) [DDS Foundation Wiki], accessed July 1, 2025, https://www.omgwiki.org/ddsf/doku.php?id=ddsf:public:guidebook:06_append:glossary:r:rtps

27. Real-Time Publish-Subscribe (RTPS) Protocol - NETWORX SECURITY, accessed July 1, 2025, https://www.networxsecurity.org/members-area/glossary/r/rtps.html

28. RTI Connext DDS - Connectivity Platform for Industrial IoT - Dedicated Systems Australia, accessed July 1, 2025, https://dedicatedsystems.com.au/products/rti-connext-dds/

29. Software Framework for Physical AI Systems | RTI - Real-Time Innovations, accessed July 1, 2025, https://www.rti.com/industries

30. RTI Connext®: The DDS Software Framework for Better, Faster Defence Systems, accessed July 1, 2025, https://vanguardcanada.com/rti-connext-the-dds-software-framework-for-better-faster-defence-systems/

31. RTI, DDS and the Industrial Internet of Things - YouTube, accessed July 1, 2025, https://www.youtube.com/watch?v=xAqKCujskxc

32. RTI Connext DDS Professional, accessed July 1, 2025, http://www.acetronix.co.kr/kor/goods/download.php?no=57

33. RTI Connext DDS Secure for autonomous systems - Electronic Specifier, accessed July 1, 2025, https://www.electronicspecifier.com/products/design-automation/rti-connext-dds-secure-for-autonomous-systems

34. RTI Connext DDS Secure - HubSpot, accessed July 1, 2025, https://cdn2.hubspot.net/hubfs/1754418/RTI_Oct2016/PDF/RTI_DDS_Secure.pdf?t=1485482280047

35. PCB 뉴스 - RTIConnext 6의 매력, accessed July 1, 2025, https://www.ipcb.com/kr/news/2700.html

36. DDS in Autonomous Car Design - Real-Time Innovations - RTI, accessed July 1, 2025, https://info.rti.com/hubfs/whitepapers/DDS_in_Autonomous_Car_Design.pdf

37. 소프트웨어 정의 차량용 RTI Connext Drive 기능 개요, accessed July 1, 2025, https://www.rti.com/hubfs/_Collateral/capability-briefs/Korean%20Capability%20Briefs/RTI-capability-brief-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4%20%EC%A0%95%EC%9D%98%20%EC%B0%A8%EB%9F%89%EC%9A%A9RTI-Connext-Drive%EA%B8%B0%EB%8A%A5%20%EA%B0%9C%EC%9A%94.pdf

38. 소프트웨어 정의 차량을 위한 자동차 통신 프레임워크 리더, accessed July 1, 2025, https://www.rti.com/hubfs/_Collateral/Executive-Briefs/RTI-executive-brief-Connectivity-Leader-for-SDV-KR.pdf

39. 美RTI, 바이두 ‘아폴로’ 자율주행차 생태계 파트너로 - 로봇신문사, accessed July 1, 2025, http://www.irobotnews.com/news/articleView.html?idxno=21748

40. [myLV.net 집필진 강좌] RTI DDS(Data Distribution Service) Toolkit 소개 - NI Community, accessed July 1, 2025, https://forums.ni.com/t5/Archive-%EA%B0%95%EC%A2%8C%EA%B2%8C%EC%8B%9C%ED%8C%90/myLV-net-%EC%A7%91%ED%95%84%EC%A7%84-%EA%B0%95%EC%A2%8C-RTI-DDS-Data-Distribution-Service-Toolkit-%EC%86%8C%EA%B0%9C/ta-p/3867503

41. 4. Quality of Service - The Data Distribution Service Tutorial, accessed July 1, 2025, https://download.zettascale.online/www/docs/Vortex/html/ospl/DDSTutorial/qos.html

42. https://d2vkrkwbbxbylk.cloudfront.net/sites/default/files/rti-examples/rticonnextdds-examples/examples/connext_dds/using_qos_profiles/c/my_custom_qos_profiles.xml, accessed July 1, 2025, https://d2vkrkwbbxbylk.cloudfront.net/sites/default/files/rti-examples/rticonnextdds-examples/examples/connext_dds/using_qos_profiles/c/my_custom_qos_profiles.xml

43. Advanced Tutorial Using QoS to Solve Real-World Problems - DDS Foundation, accessed July 1, 2025, https://www.dds-foundation.org/sites/default/files/DDS_Advanced_Ttutorial_00-T5_Hunt-revised.pdf

44. Safety Mechanisms Using the DDS Middleware in Software-Defined …, accessed July 1, 2025, https://www.nxp.com/company/about-nxp/smarter-world-blog/BL-SAFETY-MECHANISMS

45. 59.18 OWNERSHIP_STRENGTH QosPolicy - RTI Community, accessed July 1, 2025, https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/users_manual/users_manual/OWNERSHIP_STRENGTH_QosPolicy.htm

46. LIVELINESS QosPolicy - RTI Community, accessed July 1, 2025, https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/users_manual/users_manual/LIVELINESS_QosPolicy.htm

47. 20.1.1.7.19. LivelinessQosPolicy - 3.2.2 - Fast DDS - eProsima, accessed July 1, 2025, https://fast-dds.docs.eprosima.com/en/latest/fastdds/api_reference/dds_pim/core/policy/livelinessqospolicy.html

48. ROS QoS - Deadline, Liveliness, and Lifespan - ROS2 Design, accessed July 1, 2025, https://design.ros2.org/articles/qos_deadline_liveliness_lifespan.html

49. Quality of Service (QoS) policies are sets of requested policies for how - entities - OpenDDS, accessed July 1, 2025, https://opendds.readthedocs.io/en/master/devguide/quality_of_service.html

50. DEADLINE QosPolicy - RTI Community, accessed July 1, 2025, https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/users_manual/users_manual/DEADLINE_QosPolicy.htm

51. Shapes Demo - OpenDDS 3.32.0, accessed July 1, 2025, https://opendds.readthedocs.io/en/latest-release/devguide/shapes.html

52. Data Distribution Service - Wikipedia, accessed July 1, 2025, https://en.wikipedia.org/wiki/Data_Distribution_Service

53. What’s in the DDS Standard? - DDS Foundation, accessed July 1, 2025, https://www.dds-foundation.org/omg-dds-standard/

54. 5. Defining a data type via IDL - 3.2.2 - Fast DDS - eProsima, accessed July 1, 2025, https://fast-dds.docs.eprosima.com/en/v3.2.2/fastddsgen/dataTypes/dataTypes.html

55. data distribution service - How to model in idl for DDS - Stack Overflow, accessed July 1, 2025, https://stackoverflow.com/questions/15337914/how-to-model-in-idl-for-dds

56. Introducing Xtypes for OpenDDS - YouTube, accessed July 1, 2025, https://m.youtube.com/watch?v=9kNAmtjloH4

57. CoreDX DDS Dynamic and Extensible Topic Types (X-Types) - Twin Oaks Computing, Inc, accessed July 1, 2025, https://www.twinoakscomputing.com/coredx/coredx_xtypes

58. RTI Connext Core Libraries Extensible Types Guide, accessed July 1, 2025, https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/extensible_types_guide/RTI_ConnextDDS_CoreLibraries_ExtensibleTypes_Guide.pdf

59. What XTypes can do for you - Eclipse Cyclone DDS - FAQ, accessed July 1, 2025, https://cyclonedds.io/content/blog/xtypes-features.html

60. Chapter 38 Data Fragmentation - RTI Community, accessed July 1, 2025, https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/users_manual/users_manual/LargeData_Fragmentation.htm

61. What do I need to send Large Data successfully? | Data Distribution Service (DDS) Community RTI Connext Users, accessed July 1, 2025, https://community.rti.com/kb/what-do-i-need-send-large-data-successfully

62. PUBLISH_MODE QosPolicy (DDS Extension) - RTI Community, accessed July 1, 2025, https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/users_manual/users_manual/PUBLISH_MODE_QosPolicy__DDS_Extension_.htm

63. RTI Connext .NET API (legacy): DDS::AsynchronousPublisherQosPolicy Class Reference, accessed July 1, 2025, https://community.rti.com/static/documentation/connext-dds/6.1.2/doc/api/connext_dds/api_dotnet/classDDS_1_1AsynchronousPublisherQosPolicy.html

64. async_publisher.c, accessed July 1, 2025, https://d2vkrkwbbxbylk.cloudfront.net/sites/default/files/rti-examples/rticonnextdds-examples/examples/connext_dds/asynchronous_publication/c/async_publisher.c

65. Three Simple Steps to Achieving Peak DDS Performance | RTI, accessed July 1, 2025, https://www.rti.com/blog/three-simple-steps-to-achieving-peak-dds-performance/

66. rticommunity/rtiperftest: RTI Perftest is a command-line application that measures the Latency and Throughput of very configurable scenarios that use RTI Connext DDS middleware to send messages. - GitHub, accessed July 1, 2025, https://github.com/rticommunity/rtiperftest

67. Tune Your OS for Performance | Data Distribution Service (DDS) Community RTI Connext Users, accessed July 1, 2025, https://community.rti.com/best-practices/tune-your-os-performance

68. Useful tools to debug DDS issues | Data Distribution Service (DDS) Community RTI Connext Users, accessed July 1, 2025, https://community.rti.com/howto/useful-tools-debug-dds-issues

69. ISO 26262 – Functional Safety for Automotive | TÜV SÜD - TUV Sud, accessed July 1, 2025, https://www.tuvsud.com/en-us/services/functional-safety/iso-26262-automotive

70. ISO 26262 Compliance Using Approved Software Components for Road Vehicles - Real-Time Innovations, accessed July 1, 2025, https://info.rti.com/hubfs/whitepapers/ISO_26262_for_Road_Vehicles.pdf

71. Functional safety for road vehicles - ISO 26262 - DNV, accessed July 1, 2025, https://www.dnv.us/services/functional-safety-for-road-vehicles-iso-26262-82719/

72. Requirements on Data Distribution Service … - AUTOSAR.org, accessed July 1, 2025, https://www.autosar.org/fileadmin/standards/R22-11/FO/AUTOSAR_RS_DataDistributionService.pdf

73. Safe DDS - eProsima, accessed July 1, 2025, https://safe-dds.docs.eprosima.com/

74. 01/ 로보택시 시장의 변곡점 - 유진투자증권, accessed July 1, 2025, https://www.eugenefn.com/common/files/amail/20240827_B2510_leejaeil_1111.pdf

75. Streamlining Zonal Architecture with DDS and TSN - RTI, accessed July 1, 2025, https://www.rti.com/blog/streamlining-zonal-architecture-with-dds-and-tsn

76. DDS and TSN: Converging Two Communications Standards - Real-Time Innovations, accessed July 1, 2025, https://www.rti.com/dds-and-tsn

77. Future Airborne Capability Environment® (FACE) | www.opengroup.org, accessed July 1, 2025, https://www.opengroup.org/face

78. Use Cases - Connext Devs - RTI Community - Real-Time Innovations, accessed July 1, 2025, https://community.rti.com/static/documentation/developers/use-cases/index.html

79. Customer Case Study: RTI - InfluxData, accessed July 1, 2025, https://get.influxdata.com/rs/972-GDU-533/images/Customer_Case_Study_RTI.pdf

80. ROS 2: What is DDS | Data Distribution Service (DDS) Community RTI Connext Users, accessed July 1, 2025, https://community.rti.com/page/ros-2-what-dds

81. Robot Operating System 2 (ROS 2) Architecture | by Huseyin Kutluca - Medium, accessed July 1, 2025, https://medium.com/software-architecture-foundations/robot-operating-system-2-ros-2-architecture-731ef1867776

82. Webinar: Digital Health Approach by FDA - YouTube, accessed July 1, 2025, https://www.youtube.com/watch?v=7NEJYtm76j4

83. Comparing the Performance of Zenoh, MQTT, Kafka, and DDS, accessed July 1, 2025, https://zenoh.io/blog/2023-03-21-zenoh-vs-mqtt-kafka-dds/

84. How Does DDS Compare to other IoT Technologies? - DDS Foundation, accessed July 1, 2025, https://www.dds-foundation.org/features-benefits/

85. REST vs RESTful API: Key Differences According to a Developer - Hevo Data, accessed July 1, 2025, https://hevodata.com/learn/rest-vs-restful-apis/

86. 5. REST API - RTI Web Integration Service 7.5.0 documentation, accessed July 1, 2025, https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/services/web_integration_service/using_rest_api.html

87. Fast DDS TSC RMW report 2021 - GitHub Pages, accessed July 1, 2025, https://osrf.github.io/TSC-RMW-Reports/humble/eProsima-response.html

88. eProsima/Fast-DDS: The most complete DDS - Proven: Plenty of success cases. Looking for commercial support? Contact info@eprosima.com - GitHub, accessed July 1, 2025, https://github.com/eProsima/Fast-DDS

89. c# - DDS - Which one is recommended - OpenSplice or CoreDX? - Stack Overflow, accessed July 1, 2025, https://stackoverflow.com/questions/38220008/dds-which-one-is-recommended-opensplice-or-coredx

90. A Security Analysis of the Data Distribution Service (DDS) Protocol | Trend Micro, accessed July 1, 2025, https://documents.trendmicro.com/assets/white_papers/wp-a-security-analysis-of-the-data-distribution-service-dds-protocol.pdf

91. Compilibility problems of eProsima FastDDS and RTI Context DDS, accessed July 1, 2025, https://community.rti.com/forum-topic/compilibility-problems-eprosima-fastdds-and-rti-context-dds

92. Is OpenSplice DDS compatibile with DDS from other vendors?, accessed July 1, 2025, https://kbase.zettascale.tech/article/vortex-opensplice-compatibility/

93. ROS 2 middleware interface - ROS2 Design, accessed July 1, 2025, https://design.ros2.org/articles/ros_middleware_interface.html

94. Different ROS 2 middleware vendors, accessed July 1, 2025, https://docs.ros.org/en/rolling/Concepts/Intermediate/About-Different-Middleware-Vendors.html

95. RTI Connext DDS - ROS 2 Documentation: Humble documentation, accessed July 1, 2025, https://docs.ros.org/en/humble/Installation/RMW-Implementations/DDS-Implementations/Working-with-RTI-Connext-DDS.html

96. About different ROS 2 DDS/RTPS vendors, accessed July 1, 2025, https://docs.ros.org/en/foxy/Concepts/About-Different-Middleware-Vendors.html

97. Get Started with DDS Blockset - MathWorks, accessed July 1, 2025, https://www.mathworks.com/help/dds/get-started-with-dds-blockset.html

98. How to Use DDS Middleware with Simulink - MathWorks, accessed July 1, 2025, https://se.mathworks.com/videos/how-to-use-dds-middleware-with-simulink-1643693217203.html

99. Download RTI Connext for MathWorks Users - Real-Time Innovations, accessed July 1, 2025, https://www.rti.com/third-party-integrations/connext-for-mathworks-users

100. DDS Blockset Shapes Demo - MATLAB & Simulink - MathWorks, accessed July 1, 2025, https://www.mathworks.com/help/dds/ug/dds-blockset-shapes-demo.html

101. DDS Blockset with RTI Connext Using Shapes Demo - MATLAB & Simulink - MathWorks, accessed July 1, 2025, https://www.mathworks.com/videos/dds-blockset-with-rti-connext-using-shapes-demo-1623839508696.html

102. Learn About Basic DDS Concepts - Interactive Shapes Demo | RTI - Real-Time Innovations, accessed July 1, 2025, https://www.rti.com/free-trial/shapes-demo

103. RTI Shapes Demo: User’s Manual | PDF | Network Architecture | System Software - Scribd, accessed July 1, 2025, https://www.scribd.com/document/638972276/Untitled

104. Hands-on examples for getting started with RTI Connext DDS - GitHub, accessed July 1, 2025, https://github.com/rticommunity/rticonnextdds-getting-started

105. rticonnextdds-gateway/LICENSE.md at master - GitHub, accessed July 1, 2025, https://github.com/rticommunity/rticonnextdds-gateway/blob/master/LICENSE.md

106. RTI DDS Connext® for UEI Users - Aerospace DAQ, Test, HIL - United Electronic Industries, accessed July 1, 2025, https://www.ueidaq.com/products/rti-dds-connext-for-uei-users

107. RTI Announces Free Community Access to World-Leading DDS Implementation, accessed July 1, 2025, https://www.defenceiq.com/defence-technology/press-releases/rti-announces-free-community-access-to-world-leadi

108. Forums | Data Distribution Service (DDS) Community RTI Connext Users, accessed July 1, 2025, https://community.rti.com/forum

109. 4 reasons, why DDS communication is not working - YouTube, accessed July 1, 2025, https://www.youtube.com/watch?v=r_IEn1HbHX0

110. Typical Reasons for Connext DDS Discovery Failing and Suggested Solutions, accessed July 1, 2025, https://community.rti.com/howto/typical-reasons-connext-dds-discovery-failing-and-suggested-solutions

111. DDS on myRIO Stops Working After Reset - NI Community - National Instruments, accessed July 1, 2025, https://forums.ni.com/t5/RTI-DDS-Toolkit-for-LabVIEW/DDS-on-myRIO-Stops-Working-After-Reset/td-p/3661345